Büyüyen bir hizmet işinde altyapı dağınıklığı nadiren bir karardır. Birikir.
Bir ürün, o an uygun olan barındırmada yayına girer. İkinci ürün, farklı biri kurduğu için başka bir yerde. Bir tanıtım sitesi üçüncü bir platformda. E-posta, alan adının kaydedildiği yerde. Her seçim tek başına makuldü ve topluca kimsenin ezberden tarif edemeyeceği bir yapı ürettiler.
Bu yazı bunları toparlamakla ilgili — ve özellikle işlem sırasıyla; çünkü bir göçün sıkıcı mı yoksa olaylı mı geçeceğini belirleyen şey sıradır.
Gerçekten güvendiğiniz bir envanterle başlayın
Herhangi bir mimariden önce, var olanı yazın. Var olması gerekeni değil.
Her uygulama için: nerede çalışıyor, neye bağımlı, kim kullanıyor, hangi veriyi tutuyor, bir saat kapalı kalırsa ne olur ve onu daha önce yedekten geri yükleyen olmuş mu.
Bu son sütun genellikle ilginç olanıdır. Bu tür yapıların çoğunda kayda değer sayıda uygulamanın hiç test edilmemiş yedekleri vardır; yani test edilmemiş bir yangın alarmının yangın alarmı olduğu anlamda yedekleri vardır.
Envanter aynı zamanda kimsenin belgelemediği bağımlılıkları keşfettiğiniz yerdir — bir sunucudaki, başka bir uygulamanın okuduğu tabloyu dolduran zamanlanmış görev gibi.
Tasarlamadan önce sınıflandırın
Her şey aynı muameleyi hak etmez ve aksini varsaymak, göçlerin nasıl devasa hâle geldiğidir.
Bizde tutan kaba bir sınıflandırma:
İş açısından kritik. Müşteriye dönük, müşteri verisi tutuyor, durursa gelir duruyor. Bunlar yönetilen veritabanları, gerçek yedekleme ve kurtarma, izleme ve test edilmiş bir geri yükleme prosedürü ister.
Operasyonel olarak önemli. Dâhili araçlar, yönetim panelleri. Bir kesinti aksatıcıdır ama telafi edilebilir. Standart barındırma, yedeklenmiş, izlenen.
Statik veya arşiv. Tanıtım siteleri, dokümantasyon, kimsenin dokunmadığı eski projeler. Bunlar mevcut en ucuz ve en basit şeyi ister — çoğu zaman bir CDN arkasında nesne depolama.
Dağınıklığın çoğu, üçüncü kategorideki şeylerin birinci kategoriye uygun kaynak tüketmesinden ibarettir. Bunu ayıklamak en hızlı maliyet kazancıdır ve neredeyse hiç risk taşımaz.
Herhangi bir şeyi taşımadan önce ortamları ayırın
Geliştirme, hazırlık ve üretim altyapıyı paylaşıyorsa — ya da daha kötüsü, hazırlık ortamı hiç yoksa — gerekirse mevcut barındırmada, önce bunu düzeltin.
Sebebi pratik. Provasını yapacak bir yer olmadan bir göçün provasını yapamazsınız. Doğrudan üretim üzerinde yürütülen bir göç, göç değildir; içinde müşteriler olan canlı bir deneydir.
Ortam ayrımı aynı zamanda pek çok gizli sorunun yüzeye çıktığı noktadır: koda gömülü kimlik bilgileri, yalnızca tek bir sunucuda bulunan yapılandırma, iki yıl önce elle yüklenmiş bir dosyaya bağımlılık. Bunları geçiş sırasında değil, bir hazırlık derlemesinde bulmak daha iyidir.
Sıra: veri en son
Bizde işleyen sıra:
- Statik varlıklar ve tanıtım siteleri. En düşük risk, anında fayda ve yeni kurulumu — DNS, sertifikalar, CDN, dağıtım — önemli hiçbir şey riske girmeden çalıştırır.
- Dâhili araçlar. Gerçek uygulamalar, gerçek kullanıcılar; ama kullanıcılar bir soruna tahammül edebilen ve net biçimde bildirebilen meslektaşlar.
- Durumsuz uygulama katmanları. Veritabanı yerinde dururken hesaplamayı taşıyın. Bu geri alınabilir: ters giderse trafiği geri yöneltirsiniz.
- Veritabanları. En son; çünkü en az geri alınabilir adım ve veri kaybının mümkün olduğu adım budur.
- E-posta ve iletişim. Bilinçli olarak ayrı; çünkü e-posta itibar durumu taşır — gönderen alan adları, ısınma, teslim edilebilirlik — ve bunlar anında taşınmaz.
Sıranın ardındaki ilke şu: her adım, geri alınamayacak olana kadar geri alınabilir olmalı.
Yedekleme ve kurtarma bir aşama değil, işin amacıdır
Yedeklemeyi göçten sonra yapılandırılacak bir şey gibi görmek kolaydır. Oysa göçün gerekçesi olmalıdır.
Bitirdiğinizde doğru olması gerekenler:
- Yedekler otomatik ve şifreli, anahtarlar veriden ayrı yönetiliyor.
- Saklama süresi veri sınıfına göre tanımlı ve geç fark edilen bir sorunu atlatacak kadar uzun.
- Geri yüklemeler yapılmış olmalı. Yapılandırılmış değil. Yapılmış, süresi ölçülmüş ve belgelenmiş.
- Onu kuran kişiden başka biri, kılavuzdan bir geri yükleme yürütebiliyor.
Son madde atlanan maddedir ve sabahın üçünde önem taşıyan maddedir.
Sıkıcı felakete hazırlanın
Felaket kurtarma planlaması dramatik senaryoya yönelir. Gerçekçi olan daha küçük ve çok daha olası: kötü bir dağıtım veriyi bozar ya da biri yanlış ortamda silme çalıştırır.
O durum için şunları yazın: nasıl fark edilir, bu ne kadar sürer, geri yükleme kararını kim verir, ne kadar veri kaybedilir ve müşterilere ne söylenir. Bu yanıtlar yazılı olarak yoksa, ortada bir plan değil bir şema vardır.
Bunun Dorsko'daki yeri
Dorsko tam olarak bu toparlamayı hazırlıyor ve teknoloji sayfamızdaki bulut yol haritası, mevcut altyapının tarifi değil, hedef mimaridir. O listedeki hiçbir şey bugün bulutta üretimde değil ve listedeki her hizmet, yol haritasındaki durumuyla etiketlenmiş durumda.
Yönlendirici sebepler yukarıda anlatılanlar: 10-20 web uygulamasını tek bir güvenli temele getirmek, çok sayıda yönetilen kurumsal posta kutusunu desteklemek, kurumsal belgeleri güvenle saklamak, ortamları düzgün ayırmak, günlük şifreli yedekler almak, felaket kurtarma kurmak ve üretim verisine dokunmadan yapay zekâ destekli belge işleme denemeleri yürütecek alan yaratmak.
Bu sitede yol haritası ile çalışan yapıyı görünür biçimde ayrı tutmaya özen gösterdik. Altyapı diye sunulan bir plan, ürün diye sunulan bir yol haritasıyla aynı kategoride hatadır.