GitHub'ın kurduğu on-call kültürü
(github.blog)GitHub, Ruby on Rails ile oluşturulmuş büyük bir monolit sistemdi.
Monolit on-call yapısında en zor olan kısımlar
-
Çok büyük ve çok sayıda ürün ile özellik içerdiği için, çoğu mühendis kod tabanını yeterince anlayıp on-call sırasında kesintilere müdahale edebileceğinden emin değildi. Çağrı aldıklarında işi başka ekiplere eskale ederken, mühendis olmaktan çok bir bağlantı operatörü gibi hissetmeye başladılar.
-
On-call nöbetleri arasındaki aralık uzundu ve bir on-call nöbeti 24 saatti. Mühendisler yılda en fazla 4 kez on-call oluyordu ve nöbet sırasında yeterli bağlamı edinemiyordu.
-
İzleme ve uyarı sistemleri birçok ekibe dağılmıştı ve insanlar on-call deneyimini yalnızca 24 saat yaşadığı için, on-call izleme ve dokümantasyon iyi durumda tutulmuyordu.
-
Çoğu mühendis monolit on-call konusunda kendine güvenmediği için, tüm sistemi iyi bilen 5~10 kişi bütün production kesintilerine dahil oluyor ve on-call sorumluluğunda dengesizlik ortaya çıkıyordu.
Yeni on-call kültürü
İş organizasyonundaki engeller
-
Dosya sahipliğini netleştirmek için bir servis kataloğu oluşturup dosyaları servislere, servisleri de ekiplere eşlediler.
-
İzleme ve uyarılar tüm monolit için ayarlanmış olduğundan, her ekibin sorumlu olduğu alan için kendi izleme sistemini oluşturması sağlandı.
-
Bu işi yapacak ekip sayısı fazla olduğu için, her ekip için GitHub üzerinde issue açıldı ve kontrol listeleri sağlandı.
Kültürel ve eğitsel engeller
-
Pandemi insanlar üzerinde olumsuz etki bıraktığı için, başlangıçta düşünülenden daha fazla empati odaklı bir yaklaşım gerekti.
-
Çoğu mühendisin on-call deneyimi yoktu ve operasyon deneyimi de sınırlıydı; bu yüzden eğitimler hazırlandı ve sunuldu. On-call uzmanlarıyla çalışma saatleri belirlendi, yeterli araçlar ve dokümantasyon oluşturuldu, ayrıca yardım alınabilecek Slack kanalları açıldı.
-
Birçok mühendis, on-call'un hayatlarını ne kadar etkileyeceği konusunda endişeliydi. Deneyim azsa, on-call sırasında günlük yaşam zamanını ayarlamak zor olabilir. Bunun için on-call uzmanlarının ipuçları ve püf noktaları derlendi, ayrıca çağrı kaçırıldığında başka birinin yedek olabilmesi gibi önlemler alındı. Bu daha çok alışkanlık eksikliğiyle ilgili bir konu olduğu için, eğitimden ziyade birkaç kez on-call yapıp zaman geçtikçe rahatlık gelişecektir.
-
On-call'a iyi yanıt verememekten çok endişe edildiği için, hata yapmanın sorun olmadığı ve ne kadar iyi olunursa olunsun kesintilerin yine de yaşanabileceği konusunda insanlara güven vermeye çalışıyorlar.
-
Ürünlere göre ciddiyet seviyeleri farklı olduğundan, bazı ekiplerin 5 dakika içinde yanıt vermesi gerekirken bazı ekipler ertesi gün de ilgilenebilir. Bazıları bunun adaletsiz olduğunu söylese de, bu sadece mühendislerin ilgi alanlarının farklı olmasından kaynaklanıyor.
-
Değişiklikler uygulanırken her ekibin on-call deneyimini iyileştirmeye çok fazla zaman ayırması mümkün değil. On-call düzgün işlemiyorsa, on-call sürecinin iyileştirilmesi gerekir. Ekiplerden zamanlarının yaklaşık %20'sini teknik borcu azaltmaya ve yaklaşık %20'sini on-call deneyimini iyileştirmeye ayırmaları istendi; bunun için liderliğin uzun vadeli bir bakış açısına sahip olması gerekiyor.
4 yorum
On-call’in kabaca nasıl bir şey olduğunu bilmiyorum... Galiba destek talebi gibi bir şey mi? Bizdeki gibi telefonla müşteri yanıtlama değildir herhalde...
Bizim şirkette genelde
on-call, iki ayda bir yaklaşık bir hafta boyunca mesai dışı saatlerde sistem arızalarına gerçek zamanlı müdahale etmek anlamına geliyor. PagerDuty diye bir uygulama çok kullanılıyor; severity’si high olan bir arıza meydana geldiğinde — örneğin dead letter oluşması ya da API failure rate’in belli bir seviyeyi aşması gibi — telefona anında alarm geliyor ve şirket dizüstü bilgisayarından bağlanıp logları kontrol ederek gerekli önlemleri alıyoruz.Nöbet olarak düşünebilirsiniz.
Nöbet ya da haftalık görev gibi bir his veriyor. Arıza müdahalesini sırayla yapıyorlar..