Bir ağ mühendisinin gerçekliği (erişte ve tuzla mı?)
Son zamanlarda mühendislerle çeşitli olayları tartışırken ilginç bir model fark ettim.
Bu tartışmalarda her zaman “temel neden” sorusu gündeme geliyor. Sadık okuyucular muhtemelen biliyorlardır üzerinde . Pek çok kuruluşta olay analizi tamamen bu kavrama dayanmaktadır. Sebep-sonuç ilişkilerini belirlemek için farklı teknikler kullanırlar. . Bu yöntemler, sözde "olayların doğrusallığı"nı tartışılmaz bir dogma olarak kabul eder.
Bu fikre karşı çıktığınızda ve karmaşık sistemlerde doğrusallığın güven verici derecede aldatıcı olduğuna dikkat çektiğinizde büyüleyici bir tartışma doğar. Tartışmacılar, yalnızca "temel nedene" ilişkin bilginin, olup biteni anlamamıza olanak sağlayacağı konusunda tutkuyla ısrar ediyorlar.
İlginç bir model fark ettim: geliştiriciler ve geliştiriciler bu fikre farklı tepkiler veriyor. Deneyimlerime göre geliştiriciler, temel nedenin önemli olduğunu ve olaylarda neden-sonuç ilişkilerinin her zaman kurulabileceğini iddia etme eğilimindedir. Öte yandan DevOps, karmaşık bir dünyanın her zaman doğrusallığa uymadığı konusunda çoğunlukla hemfikirdir.
Bunun neden olduğunu hep merak etmişimdir? Ne markaları programcıların "temel nedenin bir efsane olduğu" fikrini bu şekilde eleştirmesine ne gerek var? Yabancı bir ajanı tanıyan bir bağışıklık sistemi gibi. Devoplar neden bu şekilde tepki veriyorlar? oldukça eğimli Bu fikri düşünüyor musun?
Tam olarak emin değilim ama bu konuda bazı düşüncelerim var. Bu profesyonellerin günlük işlerini yürüttükleri farklı bağlamlarla ilgilidir.
Geliştiriciler genellikle deterministik araçlarla çalışır. Elbette derleyiciler, bağlayıcılar, işletim sistemleri - bunların hepsi karmaşık sistemlerdir, ancak bunların deterministik bir sonuç verdiği gerçeğine alışkınız ve bunların deterministik olduğunu düşünüyoruz: eğer aynı girdi verilerini sağlarsak, o zaman genellikle bu sistemlerden aynı çıktı. Çıktıda bir sorun varsa ("hata"), geliştiriciler bunu girdi verilerini (kullanıcıdan veya geliştirme süreci sırasında bir dizi araçtan) analiz ederek çözerler. Bir "hata" ararlar ve ardından giriş verilerini değiştirirler. Bu "hata"yı düzeltir.
Yazılım geliştirmenin temel varsayımı: aynı girdi verileri güvenilir ve deterministik olarak aynı çıktıyı üretir.
Aslında, deterministik olmayan bir sonucun kendisi bir hata olarak kabul edilir: beklenmedik veya hatalı çıktı yeniden üretilmezse, geliştiriciler araştırmayı yığının diğer bölümlerine (işletim sistemi, ağ vb.) az çok deterministik olarak, aynı girdi verileriyle aynı sonucu üretmek... ve değilse, o zaman bu hala bir hata olarak kabul ediliyor. Bu artık bir işletim sistemi veya ağ hatası.
Her durumda, determinizm, programcıların yaptığı çoğu iş için temel ve neredeyse kabul edilen bir varsayımdır.
Ancak gününü donanım toplamakla veya bir bulut API'sini bulmakla geçiren herhangi bir geliştirici için, tamamen deterministik bir dünya fikri (tüm girdilerin haritasını çıkarmak bile mümkün olduğu sürece!) en iyi ihtimalle geçici bir kavramdır. Bir kenara koysan bile deneyimli mühendisler bu dünyadaki en tuhaf şeyleri gördüler. Bunu biliyorlar Çevredeki milyonlarca diğer faktörden bahsetmiyorum bile.
Dolayısıyla deneyimli mühendislerin tüm olayların tek bir temel nedene sahip olduğundan ve "Beş Neden" gibi tekniklerin doğru bir şekilde (ve tekrar tekrar!) bu temel nedene yol açacağından şüphe duyması daha kolaydır. Aslında bu, yapboz parçalarının pratikte tam olarak uymadığı kendi deneyimleriyle çelişiyor. Dolayısıyla bu fikri daha kolay kabul ediyorlar.
Elbette geliştiricilerin saf, aptal olduklarını veya doğrusallığın nasıl aldatıcı olabileceğini anlayamadıklarını söylemiyorum.
Ancak bana öyle geliyor ki bu tartışmalarda geliştiricilerin ortak tepkisi çoğunlukla determinizm kavramının genel olarak onlara iyi hizmet ediyor günlük işlerde. Mühendisler altyapılarında Schrödinger'in kedilerini yakalamak zorunda kaldıkları için nondeterminizmle sık sık karşılaşmıyorlar.
Bu, gözlemlenen geliştirici reaksiyonlarını tam olarak açıklamayabilir ancak reaksiyonlarımızın birçok faktörün karmaşık bir karışımı olduğunu güçlü bir şekilde hatırlatır.
İster tek bir olayla uğraşalım, ister bir yazılım teslim hattı üzerinde işbirliği yapıyor olalım, ister daha geniş bir dünyayı anlamlandırmaya çalışalım, bu karmaşıklığı hatırlamak önemlidir.
Kaynak: habr.com