Pilot gibi checklist'le release çıkmak
Uçak Kazası Raporu belgeselini izlemeye bayılırım, hele ki orijinal dilinden çok Türk dublaj sanatçılarından Fatih Özacun’un seslendirmesine ayrıca hayranlık duyarım. Havacılık merakım nereden geliyor bilmiyorum ama havacılığı, uçakları, uçak yolculuğunu ve bomboş uzakta giden bir uçağı izlemeyi her zaman çok severim.
Bu yazının hikâyesi de o bölümlerden biri olabilirdi. Her şey 30 Ekim 1935’te, Ohio’daki Wright Field’da başlıyor. Boeing o güne kadar yapılmış en gelişmiş bombardıman uçağını, Model 299’u test uçuşuna çıkarıyor. Uçak kalkıyor, tırmanıyor, stall oluyor ve düşüyor. İçerideki beş kişiden ikisi hayatını kaybediyor, biri de pilot.
Pilot sıradan biri değil: Binbaşı Ployer Hill, Army Air Corps’un uçuş testleri şefi. Ondan daha deneyimli bir pilot bulmak zor. Unuttuğu şey ise çok küçük: gust lock1 Gust lock, uçak park hâlindeyken rüzgâr kumanda yüzeylerini oraya buraya savurmasın diye onları kilitleyen parça. Apronda hayat kurtarır, pistte ve havada öldürür. hâlâ takılı. Dönemin bir gazetesi 299 için “tek bir pilotun baş edemeyeceği kadar karmaşık bir uçak” diye yazıyor.
İlk akla gelen “daha çok eğitim” olurdu ama ordunun baş test pilotunu daha fazla eğitmenin pek anlamı yok. Bir grup test pilotu başka bir şey yapıyor: taksi, kalkış, uçuş ve iniş adımlarını bir karta yazıyorlar. Gawande’nin anlattığına göre 299 bundan sonra 1,8 milyon mil kazasız uçuyor, ordu da bu uçaktan neredeyse on üç bin tane sipariş ediyor. Bugün onu B-17 olarak biliyoruz.
İki türlü unutuyoruz
Birincisini 299 gösteriyor: tek insanın zihnine sığmayacak kadar çok adım. Yeni bir sistem ayağa kaldırıyorsun ya da hiç dokunmadığın bir tabloda migration koşuyorsun. Henüz hiçbir şey rutin değil, her şeyi aynı anda aklında tutman gerekiyor.
İkincisi tam tersi. Bin kere yaptığın adımı atlıyorsun, çünkü bugüne kadar atladığında hiçbir şey olmadı. Rollback’i test etmiyorsun, geçen sefer çalışmıştı. Flag’in kapalı olduğunu varsayıyorsun, genelde kapalı oluyor.
İkisinin sonu da aynı yere çıkıyor: sadece birinin kafasında duran bir adıma. Bu adımları kafamızdan çıkarıp daha sağlam bir yere koymamız lazım.
İki tür checklist
Atul Gawande cerrah. The Checklist Manifesto’yu yazarken Boeing’e gidip kokpit checklist’lerini tasarlayan Daniel Boorman’la konuşuyor. Kitap da checklist’in kokpitte neden işe yaradığını, ameliyathanede nasıl işe yarayabileceğini anlatıyor. Boorman’ın ilk sorusu şu: sana ne tür bir checklist lazım?
Read-do (oku-yap): satırı okuyorsun, sonra yapıyorsun. Nadiren ve stres altında yaptığın işler için: incident runbook’u, veritabanı restore’u. Kimse senden ezbere bilmeni beklemiyor, listeyi takip etmeni bekliyor.
Do-confirm (yap-teyit et): işi ezberden yapıyorsun, sonra durup listeyle karşılaştırıyorsun. PR şablonu, release kontrolü bu türden. Becerine güveniyor, gözünden kaçanı yakalıyor.
Bence yazılımdaki checklist’lerin çoğu yanlış türde olduğu için çalışmıyor. On iki maddelik, adım adım yazılmış bir PR şablonu düşün: do-confirm olması gerekirken read-do gibi yazılmış. Kimse PR açarken şablonu satır satır takip etmiyor, sonunda okumadan hepsini tikleyip geçiyor. Tersi de var: “yedeklerin sağlam olduğunu doğrula” diyen bir restore runbook’u. Gece üçte sana hangi komutu yazacağını tam olarak söylemesi lazım, o ise sadece bir komut olduğunu hatırlatıyor.
İşe yarayan checklist nasıl olur?
Boorman’ın kuralları, Gawande’nin aktardığı şekliyle:
- Duraklama noktası. Checklist bir âna ait: merge’den önce ya da deploy’dan hemen sonra gibi. “Aklına geldikçe” değil.
- Killer item’lar. Boorman’ın deyimi: atlanınca canını yakan ama yine de atlanan adımlar. Gerisinin yeri başka.
- Kısa. Kabaca kural beş ile dokuz madde. Bir duraklama noktasında bir dakikadan fazla oyalanınca insanlar kestirmeden gitmeye başlıyor.
- Test edilmiş. Önce bir provada dene, gerçek kullanımda bir boşluk çıkınca düzelt.
“Kısa” kuralı elli adımlık bir veritabanı restore’unu dışarıda bırakıyor gibi duruyor ama öyle değil. Checklist’in o duraklama noktasında kullanılacak kadar kısa olması yetiyor, detaylı adımlar zaten bağlandığı prosedürde duruyor.
Asaf Degani ve Earl Wiener, NASA için havayolu checklist’lerini inceleyen iki insan faktörleri araştırmacısı. Cevaplarla ilgili bir kural daha ekliyorlar: cevap, maddenin gerçek durumunu ya da değerini söylemeli. “Baktım” demek yetmez. Raporda bir pilotun hikâyesini aktarıyorlar: taksi sırasında “checked and set” diyor, hız işaretlerinin, yani speed bug’ların hâlâ yaklaşma ayarında kaldığını ancak kalkış koşusunda fark ediyor. Pilotun kendi yorumu: “‘checked’ ve ‘set’ hiçbir doğrulama yapmadan çok kolay söylenebiliyor.”
Biraz açayım. Kalkıştan önce pilot, kalkış kartındaki hızları hız göstergesinin kenarındaki küçük işaretlere, yani bug’lara ayarlıyor. Bunların en önemlisi V2, kalkış güvenlik hızı: bir motor dursa bile uçağın güvenle tırmanabilmesi için ulaşması gereken en düşük hız. Pilot kalkışta gözünü bu işarete göre ayarlıyor. Bug önceki inişten kalma yaklaşma hızında, mesela 132’de unutulmuşsa kart 145 dese bile pilotun takip ettiği hız 132 oluyor. Uçak olması gerekenden yavaş tırmanıyor, bir motor durursa da aradaki fark tam o anda önemli hâle geliyor.
Yazılımda bunun üstüne bir kural daha lazım: her maddenin “bitti” diyebileceğin net bir koşulu olmalı. “Dashboard’lara bakıldı” tek başına hiçbir şey söylemiyor. Neye bakılacak, ne kadar bakılacak, rollout ne zaman durdurulacak, bunları biri bilmeli.
Aşağıdaki deploy kartını bunları düşünerek yazdım. Gri satırları pipeline kontrol ediyor, ekip var olduklarını unutmasın diye kartta duruyor. Gerisi bir insanın işi. Bir satıra dokunup cevabını söyleyebilirsin.
Her cevap, birinin kontrol edebileceği bir durum. “Geri alınabilir” demek, önceki sürümün yeni şemayla hâlâ çalıştığı anlamına geliyor. Çalışmıyorsa alttaki rollback satırı aslında yalan söylüyor. “Son sürüm” de dönülecek versiyonun adı.
Checklist koda dönüşünce
Yazılımın güzel yanı şu: bazı checklist maddeleri delivery pipeline’ında zorunlu kontrollere dönüşebiliyor. Bu arada havacılık da bunun bir versiyonunu yapıyor. Boeing 777-9’da elektronik checklist bazı maddeleri doğrudan uçaktan okuyor: katlanır kanat uçları açılmamışsa Before Takeoff checklist’ini eksik sayıyor ve uyarı veriyor.
Bildiğim en net örnek, işte kurduğum gateway düzeni. Her backend ekibi kendi route dosyalarının sahibi, bu dosyalar ortak şablonlarla birlikte 500’den fazla route’luk tek bir konfigürasyona derleniyor. Tek satırlık bir değişiklikten sonra bütün konfigürasyonun hâlâ derlendiğini kontrol etmek, tam da insanların atladığı türden bir adım. O yüzden her PR’da bir pre-check konfigürasyonun tamamını derliyor ve sadece derlenen PR review’a geçiyor.
Pre-check’in karar veremediği şey yine bir insana kalıyor: merge’den önce sahibi olan ekipten bir code owner’ın onaylaması gerekiyor. Pipeline sadece birinin yazdığı koşulları kontrol edebilir. Değişikliğin iyi bir fikir olup olmadığı hâlâ insanın kararı, dikkatini de oraya vermen lazım.
Checklist’in de her kod gibi bir sahibi olmalı. Bir incident’tan ya da provadan sonra belirsiz kalan satırları düzelt, pipeline’ın artık zorunlu kıldığı satırları da griye çek ki kimse aynı şeyi iki kere kontrol etmesin. Birinin aklını kullanmasını gerektiren satırlar ise kalıyor, bir script onları tikleyebilecek olsa bile.
Son olarak şu: checklist kullanmak çoğumuza biraz ters geliyor. Gawande bunu açık açık yazıyor: checklist kullanmayı kendimize “yakıştıramıyoruz”, iyi olması beklenen biri için bir tür utanç gibi geliyor.
O zaman Wright Field’daki o sabaha bir daha dön. Kokpitte ordunun en deneyimli test pilotu oturuyor, uçmayı ondan iyi bilen yok. Uçağın kaza yapmasına sebep olan, kuyrukta unutulmuş küçücük bir kilit. Ondan sonra gelen pilotlar Hill’den daha yetenekli değildi, ellerinde bir kart vardı, o kadar. Aynı model o kartla 1,8 milyon mil tek kaza yapmadan uçtu ve B-17 oldu.
Bir dahaki deploy’a basmadan önce kendine şunu sor: benim gust lock’um ne?