Kazaları hafifletmek için makul dağıtım nasıl korunur?

Son zamanlarda Amazon S3 , ABD-Doğu-1 bölgesinde büyük bir kesinti yaşadı . Ansible'da veya benzer bir araçta bir bakım oynatma kitabı çalıştırırken muhtemelen bir yazım hatasından kaynaklanıyor gibi görünüyor. Aşağıdaki gibi görünmesi için ansible-playbook'un etrafına bir kabuk komut dosyası sarıcı koyabilirsiniz:

#!/bin/bash
/usr/bin/ansible-playbook "$@" --list-hosts --list-tasks
read -p "Are you sure? (y/n) " answer
test "$answer" = "y" || exit 0
exec /usr/bin/ansible-playbook "$@"

Ancak, güvenliği artırmak ve şirketiniz için büyük bir kesintiye neden olan hata olasılığını azaltmak için kullandığınız diğer bazı yollar nelerdir.

Dağıtımları tetiklemek için cenkins'deki işleri kullanıyoruz. Konuşlandırmayı kim yaparsa yapsın, çalıştırılan ansible komutun aynı olmasını sağlar. İyi bir bonus, dağıtımlar tetiklendiğinde, bunları kim tetiklediğinde ve dağıtım sırasında tam olarak ne olduğunda derleme günlük kaydıdır.

Kesinlikle kusursuz değildir, ancak elle tutulur oyun kitaplarının çalıştırılmasında hoş bir gelişme olmuştur.

Daha büyük / riskli değişiklikler için bu ideal olarak bir tür değişiklik yönetimi ile birleştirilmelidir, bu nedenle değişiklikler yalnızca başka bir kişi / ekip değişikliği ve olası sorunları erkenden tanımlamaya ve çözmeye yardımcı olmak için değişikliğe yaklaşımı inceledikten sonra yapılır.

Ek olarak, büyük değişiklikler yaparken yaptığınız değişikliği izleyen ve izleyen bir takım arkadaşınız asla acıtmaz, böylece değişimin yürütülmesinde hataları izleyebilir ve önlemeye yardımcı olabilirler.

Hata kategorileri

Sorunlara ve kazalara neden olan insan faktörlerine bakmanın iki yolu vardır:

1. İnsan hatasını bir yanlışlığın nedeni olarak görebilirsiniz. Bu durumda hangi etiket altında olursa olsun “insan hatası” - durum bilincinin kaybı, usul ihlali, yasal eksiklikler, yönetimsel eksiklikler araştırmanızın sonucudur.
2. İnsan hatasını daha derin bir sorunun belirtisi olarak görebilirsiniz. Bu durumda, insan hatası araştırmanızın başlangıç ​​noktasıdır. İnsan hatasının sistematik olarak insanların araçlarının, görevlerinin ve operasyonel / organizasyonel ortamın özelliklerine nasıl bağlandığını inceleyeceksiniz.

Birincisine insan yaklaşımı, ikincisine sistem yaklaşımı denir .

İnsan yaklaşımını kullanarak başarısızlığı açıklamak için başarısızlık arar ve insanların yanlış değerlendirmelerini, yanlış kararlarını veya kötü yargılarını bulurdunuz.

Sistem yaklaşımını kullanarak başarısızlığı açıklamak için insanların nerede yanlış gittiğini bulmaya çalışmıyorsunuz. Bunun yerine, onları çevreleyen koşullar göz önüne alındığında, insanların değerlendirmelerinin ve eylemlerinin o anda nasıl anlamlı olduğunu bulun.

Örneğin, Sağlık Geliştirme Enstitüsü (IHI) Donald Berwick, hasta güvenliğinin iyileştirilmesinin sistem tasarımında değişiklikler gerektirdiğini savunuyor :

... Biz insanız ve insanlar hata yaparız. Öfkeye rağmen, kedere rağmen, deneyime rağmen, en iyi çabalarımıza rağmen, en derin dileklerimize rağmen, yanıltıcı doğarız ve öyle kalacağız. Dikkatli olmak yardımcı olur, ama bizi mükemmelliğe yakın bir yere götürmez ... Çözüm, değişen iş sistemlerinde. Çözüm tasarımda. Amaç aşırı güvenlik olmalıdır. Hastanelerimizde evlerimizde olduğu kadar güvenli olmamız gerektiğine inanıyorum. Fakat bu hedefe cesaret, kınama, öfke ve utanç yoluyla ulaşamayız. Buna sadece bir değişim taahhüdü ile ulaşabiliriz, böylece normal, insan hataları sonuçla alakasız hale getirilebilir, sürekli olarak bulunabilir ve ustalıkla azaltılabilir.

Donald M Berwick. Tekrar olmasın! BMJ 2001

Hataları sistemden kaldırma

Arızadan sonra meydana gelen çeşitli yolları bulmanın (ve düzeltmenin) harika bir yolu, insanları suçlamadan kök nedenini aramaktır. Bu genellikle "suçsuz post-mortems" olarak adlandırılır ve Craft blog yazısı olarak Etsy Code kavramı üzerinde genişler. Etsy'deki insanlar diğer forumlarda ve bloglarda daha fazlasını sundular ve yazdılar .

İlk etapta hataları önlemek için bazı kültür özellikleri şarttır. Sistemde oluşturulan prosedürler ve çeşitli eserler, bunları insanlar tarafından kullanmanın çok açık ve açıklayıcı olduğunu test etmelidir. Genellikle yaratanlar tüketen değil, kopukluk ve netlik eksikliğine yol açar. Bu durumda sistemin çalıştırılması güvenli değildir, çünkü tüm varsayımları bilen tek kişi onu yaratan (ve başka hiç kimse) olan kişidir.

Etkili kontrol önlemleri

Bir hata oluştuğunda süreci durdurmak için etkili kontrol önlemleri alın. Bu bir hata kanıtıdır. Etkili kontrol önlemleri, bir hata oluştuğunda süreç hatası vererek süreçlerin devam etmesini engelleyen veya durduran tasarım değişiklikleri.

Misal:

1896'da Sakichi Toyoda, Japonya'nın “Toyoda Steam güç tezgahı” adlı ilk tezgahını icat etti. Bu gelişme üretkenliği yirmi kat artırdı ve tekstillerin kalitesi iyileşti ve Japonya'daki tekstil endüstrisinde bir devrime neden oldu. Ama işte ince ama çok önemli bir keşif ve prensip:

iğne kırıldığında, makine durdu

Sakichi Toyoda, daha sonra Toyota Üretim Sistemindeki (Yalın) sütunlardan biri haline gelecek olan Loom için bir yenilik yarattı. Şimdi Jidoka dediğimiz bu sütun, bazen “insan dokunuşuyla akıllı otomasyon” veya “özerklik” olarak adlandırılıyor.

Büyük ölçüde, Andon (ilk kusurda dur) ve Poka-Yoke (hata prova), Tezgahtan etkilerini bulan daha sonraki gelişmelerdir.

Tek Noktalı Zayıflıkları Kaldırma

Tek noktalı zayıflık terimi, sistem güvenilirliğini artırmaya yönelik bir yaklaşım olarak sistemde fazlalıkların oluşturulması anlamına gelir. Artıklık, sürece dahil olan sistemlerin veya bireylerin sayısının artırılmasıyla oluşturulur. Daha fazla yedekleme sistemine veya daha fazla kontrole (çift, üçlü veya daha fazla) sahip olmak, işlemin doğru şekilde devam etme olasılığını artırır.

Bunun en iyi örneklerinden biri "dört göz ilkesi" dir, yani "tüm iş kararları ve işlemlerin CEO ve CFO'dan onay alması gerekir. CFO CEO'ya rapor vermediğinden bağımsız bir kontrol mekanizması vardır" .

^{kaynak: https://en.wikipedia.org/wiki/Two-man_rule}

Tehlikeleri Açık Hale Getirin

Tehlikeler açık hale getirilirse veya ulaşılması imkansızsa, insanlar hata yaratamaz. Örneğin, renk kodlaması hataları daha açık hale getirmek için yaygın bir yaklaşımdır. Veya yalnızca bir yöne takılabilen, diğerine takılamayan çeşitli bilgisayar prizleri düşünüyorsanız.

Bazı harika kitaplar konuyla ilgili konuşuyor ve onlardan bahsetmeden iyi bir cevap olmaz:

• 'İnsan Hatasını' Anlamak İçin Saha Rehberi Sidney Dekker
• Site Güvenilirlik Mühendisliği: Google, Üretim Sistemlerini Nasıl Çalıştırıyor?
• Sıfır Kalite Kontrol: Kaynak Denetimi ve Shigeo Shingo tarafından Poka-Yoke Sistemi

@Bradim'in el tabanlı komutlar yerine dağıtımı başlatmak için CI / CD aracınızı kullanmasının söylediği gibi, dağıtım komut dosyalarınızı hazırlama (veya yeni oluşturulmuş) ortamınızda gerçekten test eden testler eklemek gibi, genellikle ileriye doğru iyi bir adımdır. hataları daha erken alabilirsiniz.

Ayrıca, ansible komut dosyalarınızı doğrudan çağırmak yerine, akışınıza Ansible Tower gibi araçlar da ekleyebileceğinizi de ekleyebilirim ; bu, daha kolay yürütülen değişiklikleri izlemenize olanak tanır ve size ek bir güvenlik adımı verebilir. akış.