Yedek kalkmadı: bir kesintinin saat saat günlüğü

8 Ekim sabahı iç süreçlerimiz dahil tüm sistemlerimiz dört dakika içinde çöktü. İstanbul’daki yapının Ankara’da bir yedeği vardı, ama o yedek ihtiyaç anında ayağa kalkmadı. Öğleden sonra dörde doğru asgari seviyede uygulamalar yeniden ayaktaydı; bu yazı o günün, saat saat, benim bulunduğum masadan günlüğü.

08:56 ile 09:01 arasında

8:56’da sistemleri kullanıyordum. Veritabanına bağlanmış, gün içinde yapacağım işler için ortamlarımı hazırlamıştım. Her şey sorunsuzdu, yavaşlama yoktu. “Dört dakikada ne olabilir ki?” diye düşündüğümü hatırlıyorum.

Sabah 9:00’da teknik destek ve müşteri temsilcilerinin telefonları aynı anda kitlendi. Haber yazılım ekibine ses hızıyla ulaştı, çünkü telefonların bu seviyede kitlenmesi normal değildi. Birkaç kişi siteyi ve uygulamayı açmayı denedi: hiçbiri çalışmıyordu. 9:00 ile 9:01 arasında iç süreçlerimizde kullandıklarımız da dahil bütün sistem tek tek, art arda çökmüştü.

Önce saldırı mı, değil mi

İlk aklıma gelen, bir saldırı yüzünden sunuculara erişimin kesilmiş olabileceğiydi. Bu yüzden önce ağ trafiği loglarına baktım. Olağandışı bir artış yoktu; görünen, her gün olan sabah yoğunluğuydu.

Saldırı ihtimali çıkınca DNS kayıtlarından başlayarak bütün akışı izlemeye koyulduk. Her şey olması gerektiği gibiydi ve kimse bir şey değiştirmemişti. Bu eleme işe yaradı: bütün oklar artık sunuculara ve altyapı tarafına çıkıyordu.

Burada kendi varsayımımı not etmem gerek. 7/24 izlenen bir sistemde ekibin düşüşten haberi olmama ihtimali aklıma gelmemişti. Altyapı tarafından ses çıkmayınca doğrudan yanlarına gitmek yerine kendi tarafımızı elemeyi seçtim.

09:10: sunucu değil, omurga

İlk temasta tablo hemen netleşti. Altyapı ekibi durumu çoktan fark etmiş ve çalışmaya başlamıştı. Sorun tek tek sunucular değildi; omurganın tamamı çökmüştü. Bu, kısa sürede toparlanacak bir durum olmadığı anlamına geliyordu.

09:15’te birkaç arkadaşımız yönetimi, satışı ve desteği bilgilendirdi. Mesaj açıktı: bu sürecin tamamında şirket tek bir ekip gibi hareket etmek zorundaydı. Sorunu çözmesi gereken yazılım ve altyapı ekipleriydi, ama asıl yükü müşteriyle konuşan satış ve destek taşıyacaktı. Aynı anda başka arkadaşlar son 72 saatte yapılan bütün geliştirmeleri kontrol etti. Sebep her neyse, uygulama kodunda değildi.

Şirketin kriz anındaki davranışına dair daha geniş bir yazı için Kriz anı: şirketin karakteri orada belli olur yazıma bakabilirsiniz.

10:00: B planı için beklerken

Sunucularımız İstanbul’daki bir veri merkezindeydi. Doğal afetler dahil bu türden durumlar için Ankara’daki veri merkezinde sistemlerin bir klonu vardı. Bugüne kadar hiç ihtiyaç duyulmamış, B planı olarak tutulan bir yapıydı. Altyapı ekibi her şeyi doğru biçimde ayağa kaldırmanın bir ila iki saat sürebileceğini söyleyip çalışmaya başladı.

Beklemek en zor kısımdı. Her dakika gerilim artıyordu ve elimizde yapacak bir işimiz görünmüyordu. Dayanamayıp üretime tam erişimi olan arkadaşa döndüm ve iki soru sordum.

• “Veritabanı ayakta mı?” Cevap: “Değil.”
• “Replica’lar ayakta mı, son yedek ne zaman?” Küçük bir kontrolün ardından cevap: “Replica’lar çalışıyor.”

Bu iki cevap, beklemekten başka bir şey yapabilmemizin ilk adımı oldu: elimizde, üzerine hazırlık yapabileceğimiz bir veri vardı.

10:30: kriz masası

Replica’ların ayakta olduğunu öğrenince uygulamaları başka bir sunucuda ayağa kaldırmak için hazırlanmayı önerdim. Bir dakika sonra masanın etrafında bütün ekip toplanmıştı. Ekibin daha deneyimli üyesi tahtanın başına geçti.

İlk iş envanterdi: proje ve servislerin tam listesi. Sonra öncelikli olanları seçtik. Ardından ana projelerimizin eksiksiz bağımlılık listesini çıkardık: Message Broker, Worker ve bağlı bütün mikroservisler. Aralarındaki ilişkiyi tahtaya kabaca çizdik.

Bence krizde en çok işe yarayan şey akıllı bir fikir değil, herkesin aynı tahtaya bakıyor olmasıdır.

11:30: kriz büyüyor

Altyapı ekibi, Ankara’daki sunucuları kaldıramadıklarını bildirdi. Müşteriler haklı olarak öfkeliydi ve bu öfke destek ve satış ekiplerine akıyordu. Yük, telefonun öbür ucundaki arkadaşlarımızın omzundaydı.

Yazılım ekibi olarak kendi planımızı devreye almak için uygun bir veri merkezi aramaya başladım. AWS ya da GCP, regülasyonlar nedeniyle bir seçenek değildi. Önceliğim kısa süreli bir çözümdü, çünkü zarar zaten olabildiğince büyümüştü. Ekibin büyük çoğunluğu aynı sırada başka bir işe girişti: kıyıda köşede unutulmuş, bir mikroservisin bağımlı olduğu bir şey var mı diye analiz yaptı.

12:30: asgari ürün tanımı

Altyapı ekibinden bir toplantı talebi geldi ve zaman kaybetmeden katıldık. Toplantıda birkaç yönetici de vardı. Altyapı ekibi tamamen sıfırdan yeni sunucular kurmuş, uygulamaları ve mikroservisleri ayağa kaldırmaya çalışıyordu. Bizim orada bulunma sebebimiz belliydi: asgari seviyede hangi sistem ve servislerin kalkması gerektiğini anlık olarak bildirmek ve uygulamanın doğru çalıştığını canlı olarak doğrulamak.

Öncelik tanımı da netti. Müşterilerin eksiksiz kullanabilmesi birinci sıradaydı. Acil olmayanlar ise kendi iç süreçlerimiz için kullandığımız servislerdi.

16:00 civarında asgari seviyedeki uygulamalar tamamen ayaktaydı. Sabah 9:00’dan beri yaklaşık yedi saat geçmişti.

Kullanılmamış yedek, kanıtlanmamış yedektir

Bu tür sorunlar internet uygulamaları için aslında normaldir. Teknik ekipler bunu bildiği için çoğunlukla B planı, C planı gibi fallback planlarıyla hazırlanır. O gün yaşadığımız şey bir hacking ya da saldırı değildi; son derece olağan bir problemdi.

Olağan olmayan, B ve C planlarının, yani fallback’lerimizin işe yaramamasıydı. Burada kimseyi suçlamak istemiyorum. Yedek sistem vardı; ama bugüne kadar hiç devreye girmemişti ve devreye girmesi gereken ilk gün kalkmadı. Eleştirdiğim şey bir ekip ya da kişi değil, bir pratik: hiç devreye girmemiş bir planı, devreye girmiş gibi güvenilir saymak.

O gün, öteden beri savunduğum 3 sav da ne kadar haklı olduğumu ortaya koydu.

1. Yedeğin varlığı, yedeğin çalışması değildir. “Ankara’da klonumuz var” cümlesi bir varlık beyanıdır, bir kabiliyet beyanı değil.
2. Envanter ve bağımlılık listesi, kriz başlamadan önce hazır olmalı. Bunu hep söylüyordum; o gün listeyi krizin içinde, tahtada çıkarmak zorunda kaldık.
3. Asgari ürün önceden tanımlanmalı. “Müşteri eksiksiz kullanabilsin, iç servisler beklesin” kararı kriz anında verilmemeli, önceden bir sayfaya yazılmış olmalı. O gün bu kararı toplantının ortasında vermek zorunda kaldık.

Kendi yedeğinizin en son ne zaman gerçekten kaldırıldığını düşünün. Cevabınız “hiç” ya da “hatırlamıyorum” ise, o yedek şu an sizin için bir varsayımdır.