Kademeli otomasyonun anahtarı: Do-nothing scripting (2019)

 (blog.danslimmon.com)
1 puan yazan GN⁺ 2025-02-09 | 1 yorum | WhatsApp'ta paylaş
  • Operasyon ekiplerinde, altyapı değişiklikleri veya hesap sağlama gibi tamamen ortadan kaldırılması zor manuel prosedürler (toil) kalır; şirket büyüdükçe adımlar ve istisnalar artar
  • Her adım otomatikleştirilebilir gibi görünse de yalnızca bir kısmı script’e dökülürse tek amaçlı araçlar çoğalır ve kullanıcı hâlâ uzun prosedür dokümanlarını takip etmek zorunda kalır
  • Do-nothing script gerçek işi otomatik olarak yürütmez; prosedürün her adımını bir fonksiyona sarar ve kullanıcıya adım adım talimat verir
  • Kullanıcının nerede kaldığını kaçırma veya adım atlama olasılığı azalır; geliştiricinin de daha sonra belirli bir adımdaki yönlendirme metnini gerçek otomasyon koduyla değiştirmesi kolaylaşır
  • O anki manuel iş yükünü azaltmaz, ancak otomasyonun başlama maliyetini düşürerek zaman içinde toil’ın kademeli olarak ortadan kaldırılmasını sağlar

Manuel prosedürlerin eziyete dönüştüğü an

  • Her operasyon ekibinde henüz otomatikleştirilememiş manuel prosedürler vardır ve toil’ın tamamen yok olması zordur
  • Büyüyen şirketlerde altyapı değişiklikleri veya kullanıcı hesabı sağlama gibi prosedürler kolayca büyük toil merkezleri hâline gelebilir
  • Kullanıcı hesabı sağlama prosedürü şu türden birçok adımdan geçebilir
    • Kullanıcının SSH anahtar çiftini oluşturma
    • Açık anahtarı Git’e commit edip master’a push etme
    • Build işinin tamamlanmasını bekleme
    • Çalışan dizininde kullanıcının e-posta adresini kontrol etme
    • 1Password ile özel anahtarı kullanıcıya iletme
  • Gerçek ortamlarda prosedür 20 adıma kadar uzayabilir veya süreç sırasında dallanmaları ve özel durumları sürekli izlemek gerekebilir
  • Bu tür işler yüksek konsantrasyon gerektirir; ancak ilginç bir problem çözmekten çok bir onay kutusunu daha işaretlemeye benzediği için slog hâline gelir

Kısmi otomasyonun bıraktığı boşluklar

  • Slog, otomasyon için iyi bir hedef gibi görünür
    • Her adımı otomatikleştirmenin yolu kolayca akla gelebilir
    • Bilgisayarlar talimatları insanlardan daha hızlı ve doğru şekilde yerine getirebilir
    • Pratik sapma (practical drift) yaşanma olasılığı da daha düşüktür
  • Sorun, slog otomasyonunun çoğu zaman ya hep ya hiç gibi hissettirmesidir
  • Yalnızca 2. veya 5. adımı halleden bir script yazılabilir, ancak tüm prosedürün zahmeti kayda değer ölçüde azalmaz
  • Tek amaçlı script’ler çoğaldıkça her aracın kuralları ve beklenen davranışları farklılaşır; kullanıcı hâlâ çok adımlı dokümanları takip etmek zorunda kalır

Do-nothing script’in çalışma şekli

  • Neredeyse her slog, Do-nothing script’e dönüştürülebilir
  • Temel fikir, slog’un talimatlarını koda koymak ve her adımı tek bir fonksiyon olarak kapsüllemektir
  • Örnek script’in akışı şöyledir
    • CreateSSHKeypairStep, ssh-keygen komutunu yazdırır ve kullanıcı Enter’a basana kadar bekler
    • GitCommitStep, açık anahtarı Git deposuna kopyaladıktan sonra git commit, git push çalıştırmasını söyler
    • WaitForBuildStep, build işi URL’sinde tamamlanmayı beklemesini söyler
    • RetrieveUserEmailStep, dizinde e-posta adresini bulup giriş olarak alır ve context["email"] içine kaydeder
    • SendPrivateKeyStep, 1Password’da özel anahtar dokümanı oluşturup ilgili e-posta kullanıcısıyla paylaşmasını söyler
  • Bu script, prosedürün hiçbir adımını fiilen yerine getirmez; kullanıcıya adım adım talimat verir ve manuel tamamlamayı bekler

Otomasyona giden yol

  • Do-nothing script ilk bakışta dokümantasyonu okumayı zorlaştırıyormuş gibi görünebilir; ancak gerçekte iş akışını daha güvenli biçimde elde tutar
    • Kullanıcının süreçte nerede olduğunu kaybetme veya adım atlama olasılığı düşer
    • Konsantrasyonu koruyarak slog’u sonuna kadar sürdürmek kolaylaşır
    • Her adım fonksiyon olarak ayrıldığı için belirli bir adımın metni gerçek çalışan kodla değiştirilebilir
    • Zamanla yeniden kullanılabilir bir adım kütüphanesi oluşur ve sonraki otomasyon işleri daha verimli hâle gelir
  • Do-nothing script’in kendisi ekibin manuel iş yükünü azaltmaz
  • Etkisi, otomasyona başlamayı kolaylaştıran bir durum yaratmasındadır; ekip bunun üzerine zaman içinde toil’ı ortadan kaldırabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-02-09
Hacker News yorumları

  • Bu yaklaşımı gerçekten seviyorum
    Genel olarak bakınca bu, sürecin etrafında bir arayüz tanımlamanın başka bir yolu. Süreç manuel de olabilir otomatik de, ama arayüz aynı kalabilir. Bu yüzden adımları otomatikleştirirken oldukça güçlü
    Tıpkı diğer sistemlere yaptığınız gibi uygulayabilirsiniz
    Geçmişte Google Sheets'i elle doldururken bunu bir script ile otomatikleştirmiştim; Jira ticket'ı oluşturunca onu otomatik olarak alıp işleyen bir şey de yapmıştım. Daha hızlı başlayabiliyorsunuz, yalnızca en can sıkıcı kısımları otomatikleştirebiliyorsunuz ve her şeyi mutlaka uçtan uca otomatikleştirmeniz de gerekmiyor
    Hiçbir şey yapmayan script'in bir yan etkisi de şu: dokümantasyona göre gerçekten kullanılma ihtimali daha yüksek olduğu için daha sık güncel kalabiliyor

    • Bana göre, çok da mütevazı olmayan fikrim şu: süreci bu şekilde kademeli olarak script'lerle kodlamak, süreci yutan bir sistem değil, süreç merkezli bir sistem ortaya çıkarıyor
      Sık yapılan işleri otomatikleştiren bir script listesine elbette varım. Ama bu script'ler üretim servisleri tarafından çağrılmaya başladığı anda, o spagetti ağını çözmek zorunda kalacak talihsiz kişi için devasa bir teknik borç oluşuyor
      Dahası, insan merkezli sürecin sistemi kodlamış olması, sistemi bileşenlere ayırmak gibi yazılım sistemine faydalı değişiklikleri imkânsız hale getiriyor. Sonunda kademeli genişleme, sürece daha fazla şey itmek anlamına geliyor ve bu da script monolitinin üstüne durmadan ekleme yapılan, kendi kendini büyüten bir döngüye dönüşüyor
    • Eskiden yaklaşımımız şöyleydi: 1) mevcut süreci olduğu gibi yakala 2) bu süreci ilk bakışta mantıklı görünecek hale getir 3) otomasyona uygun hale getir
      3 ve 4 üzerinde ilerlerken, süreci tekrar tekrar kullandırır, mümkün olduğunca çok kişiye kullandırır ve sahada gerçekten gördüğümüz yanlış kullanımlara göre süreci ayarlardık
      4) süreci otomatikleştir
      Herkes 1 ve 2'ye katılıyor, çoğu kişi de eninde sonunda 4'e geliyor; ama 3 yapılınca 4'ü talep eden ve anlayan insan sayısı artıyor
      Yine de bu yaklaşımın sınırı şu: sürecin başını ya da sonunu otomatikleştirebiliyorsanız iyi, ama ortada ada gibi kopuk iki otomasyon noktası varsa, bu şey prompt'lu bir komut satırı aracından daha iyi olmuyor
    • Evet. Benim için bu aynı zamanda Jupyter notebooks kullanmak ve paylaşmak için bir fırsat daha
      Yapılması gerekeni açıklayıp boilerplate, örnekler ya da parametreli çalıştırılabilir dosyalar sağlayabilirsiniz
      Notebooks'ü fiilen bir dokümantasyon sistemi gibi kullanmak harika olabilir. Ama Confluence gibi bulut SaaS'lerin üstüne katman olarak koymak için fazla ağır ve mevcut halleriyle yetki yükseltme gibi sorunlara kapı aralayabilecek çok fazla nokta var
    • “Zen and the Art of Motorcycle Maintenance” dağını görmeye başlıyorum
      Bu yaklaşım, Confluence rehber sayfasını yarı etkileşimli bir walkthrough'ya dönüştürüyor. Bu, işin bilinçli tarafı
      Diğer tarafta ise test otomasyonu var. Başta aşırı uyarlanmış XPath yığınları ve belgelenmemiş adımlarla başlıyor. Uygulama her değiştiğinde o adımları yeniden keşfetmek zorunda kalıyorsunuz. Bu da işin bilinçdışı tarafı
      Umarım zirveye ulaştığımızda hem hızlı çalıştırabiliriz hem de oraya nasıl geldiğimizi ve neden böyle olduğunu hâlâ biliyor oluruz
    • Komutla zaten yapılabilen şeyleri script'in kendisinin yapmasını isterim
      Kullanıcıya Execute command (y/N)? gibi bir onay sorabilirsiniz
      Bir terminalden ötekine kopyala-yapıştır yapmaktan gerçekten nefret ediyorum. Ciddi şekilde dikkat dağıtıyor
      Henüz komut haline gelmemiş manuel işleri ise kullanıcıya sorabilirsiniz: Look up the e-mail address for foo. Paste it here: veya Put that shit in 1Password: Are you done (y/N)?

  • İlginç bir yaklaşım
    Ama verilen örnek iş, yalnızca o şirketin SSH anahtarı dağıtım yönteminin ne kadar güvensiz olduğunu gösteriyor. Aslında kullanıcı kendi private key'ini üretmeli ve yalnızca public key'i sistem yöneticisine verip erişim yetkisi tanımlatmalı. Hiçbir noktada sistem yöneticisinin private key'in bir kopyasına sahip olmaması gerekir; geçici olarak bile. Bu yüzden 1Password adımının kendisi gereksiz olmalı
    Bu arada ben, GitHub erişimine özel SSH anahtarı üretimini ve o bağlamdaki SSH yapılandırmasını otomatikleştiren github-keygen aracının yazarım
    https://github.com/dolmen/github-keygen

    • Yeterince deneyimli olmayan kullanıcılara kendi anahtarlarını yönettirmek de pek güvenli görünmüyor. Zaten asıl mesele bunu script'e taşımak
    • Kullanıcı kendi private key'ini üretmeli ve yalnızca public key'i sistem yöneticisine vermeli adımı hep sinir bozucu şekilde uygulaması zor oldu
      Biz SSH'te sertifika tabanlı kimlik doğrulamaya geçtik ve artık public key'leri oradan oraya taşımıyoruz. Tüm süreç gerçekten çok daha basit hale geldi
    • Bu gerçekten temel kabul mü? Sonuçta IT, private key içeren iş makinesinin zaten her parçasına sahip değil mi? Parolaların farklı olduğunu biliyorum ama private key de sonuçta makinede duruyor

  • Bu yazı ilk yayımlandıktan ancak yaklaşık 1 yıl sonra sonunda bu yöntemi denedim
    Araç zincirimizdeki hatalar yüzünden hotfix runbook’u normal release sürecinden yaklaşık iki kat daha karmaşıktı
    Pek takdir görmedi ama eskiden yalnızca sev 1 sorunlarda ya da son aşamadaki epik işlerde 10 haftada bir kadar kullanılan şey, ortalama haftada 1 kez, bazı haftalarda ise 3 kereye kadar kullanılmaya başladı. Her şeyi feature toggle yapmak zorunda kalmayınca teknik borç konusuna çok daha derin girebildik
    Küçük bir şirketseniz ve production verisini pre-prod ortama kopyalamak kolaysa bu tür bir sonuç görmeyebilirsiniz. Ama bizim iletişim kurduğumuz 150’den fazla endpoint vardı ve hizmet başına ortalama yaklaşık 3 taneydi. Veri seti sayısı çok fazlaydı ve bunların bir kısmı Kafka ortaya çıkmadan önceki Kafka benzeri yöntemlerle toplanmıştı
    Production verisini kopyalamaya çalışan yalnızca bir kişi vardı; onun da zamanı ve enerjisi azdı, bu yüzden bunu yılda sadece bir iki kez yapabiliyordu. Bu tempo, müşteri ve özelliklerin değişim hızından çok daha yavaştı. Sonunda blue-green deployment süreci ve jmeter ile oynayarak yeterince yaklaşıp yaklaşmadığımızı ve canlıya almadan önce başarıyı/başarısızlığı nasıl ölçeceğimizi bulmak zorunda kaldık
    Sonuçta insanları durduran şey küçük ama hata üretmeye çok açık build süreciydi ve ben onu yarı otomatik hale getirinceye kadar sorun çözülmedi
    Daha sonra kullanım arttıkça, manuel adımlardaki tüm URL’leri bulup aracın içindeki bir lookup table’a koyduk ve bunu release onayı için kullanılan genel doğrulama sürecinde de görünür hale getirdik. Böylece koordinatör biraz daha hızlı ve daha az stresli çalışabildi. Süreç o kadar can sıkıcıydı ki yükü paylaşmak için üç ekip dönüşümlü olarak üstleniyordu

  • “İş otomasyonunun aktivasyon enerjisini düşürmek” derken, sonuçta hiçbir şey yapmayan scriptin daha sonra gerçekten bir şeyi otomatikleştiren adımlar kazanması mı kastediliyor?
    Gelecekteki otomasyon için bir yer tutucu gibi düşününce, otomasyon ile verimlilik arasında iyi bir denge gibi geliyor. Çok fazla yatırım yapmadan ilk denemeyi yapabiliyorsunuz ve daha sonra çabanın değeri daha net hale geldiğinde ele alınacak alçakta duran meyveleri bırakmış oluyorsunuz

    • Evet
      Prosedürün her adımı artık bir fonksiyon olarak kapsüllendiği için, belirli bir adımın metnini o işi otomatik yapan kodla değiştirebilirsiniz

  • class Foo(object): def run(self, context): ...
    Tek bir execute metoduna sahip nesne aslında Python’a zaten gömülü: buna fonksiyon deniyor
    def foo(context): ...

    • Ama her gün tamamen berbat bir soyutlama tüketmeden insan nasıl hayatta kalır ki?
    • İlk yaklaşımın avantajı, ileride ihtiyaç doğarsa o sınıfa ait ek private metodları kolayca ekleyebilmeniz
      Fonksiyon yaklaşımında yeni bir fonksiyon gerektiğinde bunu global seviyeye eklersiniz. Bir iki tane için bu tamamen sorun değildir ama sayı artınca aynı seviyede yığınla fonksiyon birikir ve aralarındaki bağımlılıklar artık o kadar açık olmaz
    • Brain Will’in https://www.youtube.com/watch?v=QM1iUe6IofM videosunu hatırlattı. Bu tür konular hakkında adeta söylenme serisi var
      Bunlardan birinde gereksiz yere soyutlanmış kodun nasıl sadeleştirilebileceğine dair örnekler veriyor

  • Harika ama duraklatılamıyor
    Tüm adımların en baştan gösterilip ilerledikçe her maddenin işaretlenmesi güzel olurdu. Bazen daha geniş bir perspektiften gerçekten hazırlanmak daha iyidir
    Özeti dosyaya log olarak da yazabilirsiniz
    İyileştirilebilecek çok şey var; bu yüzden belki de en basit çözüm en iyisidir

    • Daha iyi bir komut satırı kütüphanesi kullanırsanız kontrol listesini ve her adımın çıktılarını gösterebilirsiniz. Hangi adımın otomatikleştirildiğinden bağımsız olarak bu iyi bir yaklaşım
      Yine de hiçbir şey yapmayan shell script’e başlamak o kadar kolay ki onu sonuna kadar götürmemek zor. O emeği bunun yerine bir adımı otomatikleştirmeye harcamak daha iyi olabilir. Hangi TUI kütüphanesini kullanacağınız, yapıyı nasıl kuracağınız gibi eğlenceli ama çok da üretken olmayan bataklıklara saplanabilirsiniz
    • “Duraklatılamaz” noktasının açılmasına sevindim. Bu yüzden Bash script yerine Makefile kullanıyorum
      Her adım *.done adlı bir kural ve tamamlandığında bir .done dosyası üretiyor. İstediğiniz zaman durabilir, bir şeyi düzeltmek için script’i değiştirip sonra make ile kaldığınız yerden devam edebilirsiniz
      Ama o Makefile’ı yazmak gerçekten acı verici. Daha iyi bir çözüm var mı?
    • Böyle şeyler yaparken duraklatılabilmesi için kalıcı durum bırakırım. Mesela yıllık bir işse ./do-the-thing.sh 2025 gibi çalıştırır, 2025 dizinini oluşturup ne kadar ilerlediğime dair durumu orada tutarım
      İlk adımı onayladığınızda 2025/first-step dosyasına touch atabilirsiniz. Script çökerse ya da durdurulursa ve sonra yeniden çalıştırılırsa bu dosyayı kontrol edip ilk adımı atlar
      Bir şey değiştiğinde ve otomasyon çalışmadığında, durumu kaybetmeden çıkabilmek, script’i düzeltip tekrar çalıştırabilmek güzeldir
      Genelde script’in yalnızca bir sonraki manuel adımı söyleyip çıkmasını sağlarım. Böylece terminali başka işler için kullanabilirsiniz. Komut geçmişi sayesinde script’i yeniden çalıştırmak kolay olur
    • Bu gerçekten yazıya bir eleştiri mi? Bir de sonucu söylemeden çekip gitmiş. Hangi çözüm “en basit çözüm” sayılıyor?
    • Benzer bir script kullandım; yanlışlıkla hatalı bir e-posta adresi girince durum “şimdi ne olacak?”a dönüyor. Tüm script’i baştan mı başlatmak gerekiyor? Script’in içine hapsolmak gerçekten can sıkıcı olabilir

  • Önceki tartışmalar da var. Yorum çok
    https://news.ycombinator.com/item?id=29083367 - 3 yıl önce, 230 yorum
    https://news.ycombinator.com/item?id=20495739 - 6 yıl önce, 124 yorum

  • Bu yaklaşımı ne kadar sevdiğimi abartmam mümkün değil
    Bunu çeşitli projelerde başarıyla uyguladım. En sevdiğim örnek, “insan faktörleri” yüzünden laboratuvar testlerinde başarısız olan 30 milyon dolarlık cerrahi robot

    • Bir veya daha fazla örneği biraz daha ayrıntılı paylaşabilir ya da deneyimlerinizi ve ipuçlarını özetleyebilirseniz harika olur. İster burada ister bir blog yazısında, okumak isterim
      Ben farklı bir alandayım, hukuk pratiğinde çalışıyorum, ama bu yaklaşımı şirketimizde nasıl uygulayabileceğimizi düşünmek istiyorum

  • Bu yaklaşım iyi. Belli bir karmaşıklık seviyesinin üzerindeki programlama dili tabanlı sistemlerde de zaten benzerini yapmayı seviyorum. Fonksiyonel programlama tarafında buna delikler (holes) dendiğini sanıyorum
    Arayüzlerdeki not implemented hatası da benzer bir mantığı izliyor; ancak birbirine bağımlı birden çok parçanın her biri için, anlamlı olmasa da geçerli bir çıktı üreten önemsiz bir şey yazmanın ciddi bir değeri olduğunu düşünüyorum. Böylece o parçaları oluşturma süreci hızlanıyor ve bunları tek tek test edip inşa etme olasılığı çok artıyor. Teste başlamadan önce birçok bölümü aynı anda yazma ihtiyacı azalıyor
    Yazıda ele alınan kullanım örneğinde olduğu gibi, betik bağlamında bu tür tip düzeyindeki geçerliliğin önemli hale gelmesi zor olabiliyor. Komut satırındaki etkiler, fonksiyonel bakış açısından büyük ölçüde yan etkiler olacaktır. Ama işlemlerin sıralı ilerlemesi nedeniyle etkisi çok daha küçüktür ve bekleme istemi sayesinde, betik olmasa da zaten yapılması gerekecek manuel adımları küçük bir maliyetle korurken iş sırasını da muhafaza edebilirsiniz
    İskele kusurlu olsa da temelde yararlıdır

  • Teoride güzel ama pratikte zor görünüyor
    Operasyon ekibi aynı işi tekrar tekrar yapıyorsa ve hiçbir şey yapmayan betiğin gerçekten hiçbir şey yapmadığını görüyorsa, adımları ezberlediğini düşündüğü ya da bunu manuel yapmanın daha hızlı veya daha ilginç olduğunu hissettiği anda onu hızla kullanmayı bırakacaktır
    Operasyon ekipleri için çok fazla otomasyon ve dokümantasyon yazdım ama insanları bunları kullanmaya başlatmak ve kullanmaya devam ettirmek hep sorun oldu. Dokümantasyondaki değişikliklerin bile duyurulması gerekiyordu. İnsanlar bir şeyi nasıl yapacağını öğrendiğinde, çok geçmeden dokümantasyonu okumayı bırakıyor
    Mükemmel bir dünyada bu yaklaşım oldukça makul ve kişisel işlerimde ben de kullanabilirim. Ama gerçek dünya neredeyse hiç mükemmel değil. Ben olsam bu yöntemi ancak %90'ı otomatikleştirilmiş ve hâlâ çözülememiş 1 adım kalmışsa kullanırdım. O durumda bile operasyon ekibinin bir kısmı o manuel adımı atlayıp her şeyin otomatikleşmiş bir sihir olduğunu varsayabilir

    • Genellikle bazı kısımlar otomatikleştirilebilir ya da bazı manuel adımlar doğrulanabilir. O zaman birdenbire bir şey yapan betik haline gelir