12f-2'ye kadar
Nisan ayının sonunda Ak Gezenler Kışyarı'nı kuşatırken başımıza daha ilginç bir şey geldi; alışılmadık bir yayılma gerçekleştirdik. Prensip olarak biz de (herkes gibi) sürekli olarak yeni özellikleri üretime sunuyoruz. Fakat bu farklıydı. Yapabileceğimiz herhangi bir potansiyel hata, tüm hizmetlerimizi ve kullanıcılarımızı etkileyecek kadar büyüktü. Sonuç olarak, her şeyi planlandığı gibi, planlanan ve duyurulan kesinti süresi içinde, satışlar açısından herhangi bir sonuç doğurmadan hayata geçirdik. Makale bunu nasıl başardığımızı ve herkesin bunu evde nasıl tekrarlayabileceğini anlatıyor.
Şimdi aldığımız mimari ve teknik kararları anlatmayacağım veya bunların nasıl çalıştığını anlatmayacağım. Bunlar daha ziyade kenarlarda yer alan, gözlemlediğim ve doğrudan dahil olduğum en zor sunumlardan birinin nasıl gerçekleştiğine dair notlar. Eksiksiz olduğunu veya teknik ayrıntıları iddia etmiyorum; belki başka bir makalede yer alırlar.
Arka plan + bu ne tür bir işlevsellik?
Bir bulut platformu inşa ediyoruz (MCS)'de teknik direktör olarak çalışıyorum. Artık tüm kullanıcı hesaplarının, kullanıcıların, şifrelerin, rollerin, hizmetlerin ve daha fazlasının birleşik yönetimini sağlayan IAM'yi (Kimlik ve Erişim Yönetimi) platformumuza eklemenin zamanı geldi. Bulutta buna neden ihtiyaç duyulduğu açık bir sorudur: tüm kullanıcı bilgileri bulutta saklanır.
Genellikle bu tür şeyler herhangi bir projenin en başında inşa edilmeye başlar. Ancak tarihsel olarak MCS'de işler biraz farklıydı. MCS iki parça halinde inşa edildi:
- Kendi Keystone yetkilendirme modülüne sahip Openstack,
- Mail.ru Cloud projesine dayanan Hotbox (S3 depolama),
daha sonra etrafında yeni hizmetler ortaya çıktı.
Esas itibarıyla bunlar iki farklı yetkilendirme türüydü. Ayrıca, Horizon panelinde SSO'nun (uçtan uca yetkilendirme) sağlandığı, genel bir Mail.ru şifre deposunun yanı sıra kendi kendine yazılan bir openid konektörü gibi bazı ayrı Mail.ru geliştirmeleri kullandık. sanal makinelerin (yerel OpenStack kullanıcı arayüzü)
Bizim için IAM yapmak, hepsini tek bir sisteme, tamamen kendimize ait bir sisteme bağlamak anlamına geliyordu. Aynı zamanda, yol boyunca hiçbir işlevselliği kaybetmeyeceğiz, ancak gelecek için onu yeniden düzenlemeye gerek kalmadan şeffaf bir şekilde iyileştirmemize ve işlevsellik açısından ölçeklendirmemize olanak sağlayacak bir temel oluşturacağız. Ayrıca başlangıçta kullanıcıların hizmetlere (merkezi RBAC, rol tabanlı erişim kontrolü) ve diğer bazı küçük şeylere erişim için bir rol modeli vardı.
Görevin önemsiz olmadığı ortaya çıktı: Python ve Perl, birkaç arka uç, bağımsız olarak yazılan hizmetler, birkaç geliştirme ekibi ve yönetici. Ve en önemlisi muharebe üretim sisteminde binlerce canlı kullanıcı var. Bütün bunların yazılması ve en önemlisi kayıplar olmadan hayata geçirilmesi gerekiyordu.
Neyi ortaya çıkaracağız?
Çok kabaca ifade etmek gerekirse yaklaşık 4 ayda şunları hazırladık:
- Daha önce altyapının farklı bölümlerinde çalışan işlevleri bir araya getiren birkaç yeni arka plan programı oluşturduk. Hizmetlerin geri kalanına bu şeytanlar şeklinde yeni bir arka uç reçete edildi.
- Tüm hizmetlerimiz için kullanılabilen ve ihtiyaç duyduğumuzda serbestçe değiştirilebilen kendi merkezi şifre ve anahtar depomuzu yazdık.
- Keystone için sıfırdan 4 yeni arka uç (kullanıcılar, projeler, roller, rol atamaları) yazdık; bunlar aslında veritabanının yerini aldı ve artık kullanıcı şifrelerimiz için tek bir depo görevi görüyor.
- Tüm Openstack hizmetlerimize, bu politikaları her sunucudan yerel olarak okumak yerine, politikaları için bir üçüncü taraf politika hizmetine gitmeyi öğrettik (evet, Openstack varsayılan olarak bu şekilde çalışır!)
Böyle büyük bir yeniden çalışma, farklı geliştirme ekipleri tarafından yazılan çeşitli sistemlerde büyük, karmaşık ve en önemlisi eşzamanlı değişiklikler gerektirir. Montaj tamamlandıktan sonra tüm sistem çalışmalıdır.
Bu tür değişiklikler nasıl hayata geçirilir ve batırılmaz? İlk önce biraz geleceğe bakmaya karar verdik.
Kullanıma sunma stratejisi
- Ürünü birkaç aşamada piyasaya sürmek mümkün olabilir ancak bu, geliştirme süresini üç kat artıracaktır. Ek olarak, bir süreliğine veritabanlarındaki verilerin senkronizasyonunun tamamen bozulmasına neden olacaktık. Kendi senkronizasyon araçlarınızı yazmanız ve birden fazla veri deposuyla uzun süre yaşamanız gerekir. Bu da çok çeşitli riskler yaratıyor.
- Kullanıcı için şeffaf bir şekilde hazırlanabilecek her şey önceden yapıldı. 2 ay sürdü.
- Kendimize birkaç saat süreyle kapalı kalma süresi tanıdık - yalnızca kullanıcı işlemlerinin kaynak oluşturması ve değiştirmesi için.
- Halihazırda oluşturulmuş tüm kaynakların çalışması için kesinti kabul edilemezdi. Kullanıma alma sırasında kaynakların kesinti olmadan çalışması ve müşterileri etkilemesi gerektiğini planladık.
- Bir şeyler ters giderse müşterilerimiz üzerindeki etkiyi azaltmak için Pazar akşamı kullanıma sunmaya karar verdik. Daha az müşteri geceleri sanal makineleri yönetiyor.
- Tüm müşterilerimizi, kullanıma sunma için seçilen dönemde hizmet yönetiminin kullanılamayacağı konusunda uyardık.
Arasöz: kullanıma sunma nedir?
<dikkat, felsefe>
Her BT uzmanı, kullanıma sunmanın ne olduğunu kolayca yanıtlayabilir. CI/CD'yi yüklersiniz ve her şey otomatik olarak mağazaya teslim edilir. 🙂
Elbette bu doğrudur. Ancak zorluk, modern kod dağıtım otomasyon araçlarıyla kullanıma sunmanın kendisinin anlaşılmasının kaybolmasıdır. Modern ulaşıma bakarken tekerleğin icadının destansılığını nasıl da unutuyorsunuz. Her şey o kadar otomatik ki, dağıtım çoğu zaman resmin tamamı anlaşılmadan gerçekleştiriliyor.
Ve resmin tamamı böyle. Kullanıma sunma dört ana unsurdan oluşur:
- Veri değişikliği de dahil olmak üzere kodun teslimi. Mesela göçleri.
- Kod geri alma, bir şeyler ters giderse geri dönme yeteneğidir. Örneğin, yedeklemeler oluşturarak.
- Her bir kullanıma alma/geri alma işleminin süresi. İlk iki noktanın herhangi bir işleminin zamanlamasını anlamanız gerekir.
- Etkilenen işlevsellik. Hem beklenen olumlu hem de olası olumsuz etkilerin değerlendirilmesi gerekmektedir.
Başarılı bir dağıtım için tüm bu hususların dikkate alınması gerekir. Genellikle yalnızca birinci veya en iyi ihtimalle ikinci nokta değerlendirilir ve ardından kullanıma sunma başarılı kabul edilir. Ancak üçüncü ve dördüncüsü daha da önemlidir. Sunumun bir dakika yerine 3 saat sürmesi hangi kullanıcının hoşuna gider? Veya kullanıma sunma sırasında gereksiz bir şey etkilenirse? Yoksa bir hizmetin kesintisi öngörülemeyen sonuçlara mı yol açacak?
Perde 1..n, tahliyeye hazırlık
İlk başta toplantılarımızı kısaca anlatmayı düşündüm: tüm ekip, ekibin parçaları, kahvehanelerdeki yığınla tartışma, tartışmalar, testler, beyin fırtınaları. Sonra bunun gereksiz olduğunu düşündüm. Dört aylık geliştirme her zaman bundan oluşur, özellikle de sürekli olarak teslim edilebilecek bir şey yazmıyorsanız, ancak canlı bir sistem için büyük bir özellik yazıyorsanız. Bu, tüm hizmetleri etkiliyor ancak kullanıcılar için "web arayüzündeki tek tuş" dışında hiçbir şeyin değişmemesi gerekiyor.
Her yeni toplantıda, bunu nasıl hayata geçireceğimize dair anlayışımız oldukça önemli ölçüde değişti. Örneğin fatura veri tabanımızın tamamını güncelleyecektik. Ancak süreyi hesapladık ve makul bir kullanıma sunma süresinde bunu yapmanın imkansız olduğunu fark ettik. Faturalandırma veritabanını parçalamak ve arşivlemek neredeyse bir haftamızı aldı. Beklenen dağıtım hızı hala tatmin edici olmayınca, tüm tabanın sürüklendiği daha güçlü ek donanım sipariş ettik. Bunu daha erken yapmak istemediğimizden değil ama mevcut kullanıma sunma ihtiyacı bize başka seçenek bırakmadı.
Birimizin kullanıma sunulmasının sanal makinelerimizin kullanılabilirliğini etkileyeceğine dair şüpheleri olduğunda testler, deneyler, kod analizleri yapmak için bir hafta harcadık ve bunun bizim üretimimizde gerçekleşmeyeceğine dair net bir anlayış elde ettik ve en şüpheli insanlar bile aynı fikirdeydi. Bununla.
Bu arada, teknik destek ekibindeki kişiler, müşterilere, kullanıma sunulduktan sonra değişmesi beklenen bağlantı yöntemleri hakkında talimatlar yazmak için kendi bağımsız deneylerini gerçekleştirdiler. Kullanıcı deneyimi üzerinde çalıştılar, talimatlar hazırladılar ve kişisel danışmanlık sağladılar.
Mümkün olan tüm kullanıma sunma işlemlerini otomatikleştirdik. En basitleri bile her operasyon senaryolaştırıldı ve testler sürekli olarak yürütüldü. Hizmeti kapatmanın en iyi yolu hakkında tartıştılar; arka plan programını atlayın veya bir güvenlik duvarı ile hizmete erişimi engelleyin. Kullanıma sunmanın her aşaması için ekiplerin bir kontrol listesini oluşturduk ve bunu sürekli olarak güncelledik. Tüm kullanıma sunma çalışmaları için zamanlamalarla birlikte bir Gantt şeması çizdik ve sürekli olarak güncelledik.
Ve böylece ...
Yayınlanmadan önce son hareket
...dışarı çıkma zamanı geldi.
Dedikleri gibi, bir sanat eseri tamamlanamaz, yalnızca üzerinde çalışılması tamamlanır. Her şeyi bulamayacağınızı anlayarak, ancak tüm makul varsayımları yaptığınıza, olası tüm durumları sağladığınıza, tüm kritik hataları kapattığınıza ve tüm katılımcıların ellerinden geleni yaptığına inanarak irade çabası göstermelisiniz. Ne kadar çok kod yayınlarsanız, kendinizi buna ikna etmeniz o kadar zor olur (ayrıca herkes her şeyi öngörmenin imkansız olduğunu anlar).
Kullanıcılarımız için beklenmeyen etkiler ve kesintilerle ilgili tüm riskleri karşılamak için mümkün olan her şeyi yaptığımıza ikna olduğumuzda, kullanıma sunulmaya hazır olduğumuza karar verdik. Yani, aşağıdakiler dışında her şey ters gidebilir:
- Etkileyen (bizim için kutsal, en kıymetli) kullanıcı altyapısını,
- İşlevsellik: Hizmetimizin kullanıma sunulmasından sonraki kullanımı, öncekiyle aynı olmalıdır.
Kullanıma sunuluyor
İki atış, 8 karışmaz
Kullanıcılardan gelen tüm talepler için 7 saat süreyle kesinti yapıyoruz. Şu anda hem kullanıma sunma planımız hem de geri alma planımız var.
- Sunumun kendisi yaklaşık 3 saat sürer.
- Test için 2 saat.
- 2 saat - olası değişikliklerin geri alınması için rezervasyon yapın.
Her eylemin ne kadar sürdüğü, sırayla ne olduğu, paralel olarak ne yapıldığı için bir Gantt şeması hazırlanmıştır.
İlk versiyonlardan biri olan (paralel yürütme olmadan) kullanıma sunma Gantt şemasının bir parçası. En Değerli Senkronizasyon Aracı
Tüm katılımcıların sunumdaki rolleri, hangi görevleri yapacakları ve nelerden sorumlu oldukları belirlenir. Her aşamayı otomatikleştirmeye, kullanıma sunmaya, geri almaya, geri bildirim toplamaya ve tekrar kullanıma sunmaya çalışıyoruz.
Olayların tarihçesi
Böylece 15 Nisan Pazar günü saat 29'de 10 kişi işe geldi. Kilit katılımcılara ek olarak, bazıları sadece takımı desteklemek için geldiler ve onlara özel teşekkürlerimizi sunduk.
Ayrıca anahtar testçimizin tatilde olduğunu da belirtmekte fayda var. Test etmeden kullanıma sunmak mümkün değil, seçenekleri araştırıyoruz. Bir meslektaşımız, tüm ekipten büyük şükran duyduğu tatilden bizi test etmeyi kabul ediyor.
00:00. Durmak
Kullanıcı isteklerini durduruyoruz, teknik çalışma yazan bir tabela asıyoruz. İzleme çığlık atıyor ama her şey normal. Düşmesi gerekenden başka hiçbir şeyin düşmediğini kontrol ediyoruz. Ve göçle ilgili çalışmalara başlıyoruz.
Herkesin nokta nokta basılı bir sunum planı var, herkes kimin ne yaptığını ve ne anda olduğunu biliyor. Her eylemin ardından zamanlamalarını aşmadığımızdan ve her şeyin planladığımız gibi gittiğinden emin olmak için kontrol ediyoruz. Mevcut aşamada dağıtıma doğrudan katılmayanlar, meslektaşlarını rahatsız etmemek için çevrimiçi bir oyuncak (Xonotic, tip 3 şarlatanlar) piyasaya sürerek hazırlanıyorlar. 🙂
02:00. Dışarı haddelenmiş
Hoş bir sürpriz; veritabanlarımızın ve geçiş komut dosyalarımızın optimizasyonu nedeniyle kullanıma sunma işlemini bir saat önce tamamlıyoruz. Genel çığlık, "dışarı çıktı!" Tüm yeni işlevler üretim aşamasındadır ancak şu ana kadar bunları yalnızca arayüzde görebilmekteyiz. Herkes test moduna giriyor, onları gruplara ayırıyor ve sonunda ne olduğunu görmeye başlıyor.
Pek iyi sonuçlanmadı, bunu 10 dakika sonra, ekip üyelerinin projelerinde hiçbir şeyin bağlı olmadığı veya çalışmadığı bir zamanda anlıyoruz. Hızlı senkronizasyon, sorunlarımızı dile getiriyoruz, öncelikleri belirliyoruz, ekiplere ayrılıyoruz ve hata ayıklamaya geçiyoruz.
02:30. İki büyük sorun ve dört göz
İki büyük sorunla karşılaşıyoruz. Müşterilerin bazı bağlantılı hizmetleri göremediklerini ve iş ortağı hesaplarında sorunlar ortaya çıkabileceğini fark ettik. Her ikisi de bazı uç durumlar için kusurlu geçiş komut dosyaları nedeniyledir. Şimdi bunu düzeltmemiz gerekiyor.
Bunu kaydeden sorguları en az 4 gözle yazıyoruz. Çalıştıklarından ve herhangi bir şeyi kırmadıklarından emin olmak için bunları üretim öncesi test ediyoruz. Devam edebilirsin. Aynı zamanda, birkaç sorunu daha ortaya çıkaran düzenli entegrasyon testlerimizi yürütüyoruz. Hepsi küçük ama aynı zamanda onarılmaları gerekiyor.
03:00. -2 problem +2 problem
Önceki iki büyük sorun ve neredeyse tüm küçük sorunlar düzeltildi. Düzeltmelerle meşgul olmayanların tümü aktif olarak hesaplarında çalışıyor ve bulduklarını rapor ediyor. Öncelik belirliyor, ekipler arasında dağıtıyor ve kritik olmayan eşyaları sabaha bırakıyoruz.
Testleri tekrar yapıyoruz, iki yeni büyük sorun keşfediyorlar. Hizmet politikalarının tamamı doğru şekilde ulaşmadığından bazı kullanıcı istekleri yetkilendirmeyi geçemiyor. Ayrıca ortak hesaplarıyla ilgili yeni bir sorun. Bakmak için acele edelim.
03:20. Acil durum senkronizasyonu
Yeni bir sorun düzeltildi. İkincisi için acil durum senkronizasyonu düzenliyoruz. Neler olduğunu anlıyoruz: Önceki düzeltme bir sorunu çözdü ancak başka bir sorun yarattı. Bunu nasıl doğru ve sonuçsuz yapacağımızı bulmak için ara veriyoruz.
03:30. Altı göz
Tüm ortaklar için her şeyin yolunda gitmesi için üssün son durumunun ne olması gerektiğini anlıyoruz. 6 gözlü bir talep yazıyoruz, ön üretime alıyoruz, test ediyoruz, üretime sunuyoruz.
04:00. Her şey çalışıyor
Tüm testler geçti, kritik bir sorun görünmüyor. Zaman zaman takımda bir şeyler birilerinin işine yaramıyor, anında tepki veriyoruz. Çoğu zaman alarm yanlıştır. Ancak bazen bir şey gelmiyor veya ayrı bir sayfa çalışmıyor. Oturuyoruz, düzeltiyoruz, düzeltiyoruz, düzeltiyoruz. Ayrı bir ekip, son büyük özellik olan faturalandırmayı kullanıma sunuyor.
04:30. Dönüşü olmayan nokta
Geri dönüşü olmayan nokta yaklaşıyor, yani geri dönmeye başlarsak bize verilen kesinti süresini karşılayamayacağımız dönem yaklaşıyor. Her şeyi bilen ve kaydeden, ancak müşterilerden para yazmayı inatla reddeden faturalandırmayla ilgili sorunlar var. Bireysel sayfalarda, eylemlerde ve durumlarda çeşitli hatalar var. Ana işlevsellik çalışıyor, tüm testler başarıyla geçiyor. Dağıtımın gerçekleştiğine karar verirsek geri dönmeyeceğiz.
06:00. Kullanıcı arayüzündeki herkese açık
Hatalar düzeltildi. Kullanıcılara hitap etmeyen bazıları ise daha sonraya bırakıldı. Arayüzü herkese açıyoruz. Faturalandırma üzerinde çalışmaya, kullanıcı geri bildirimlerini beklemeye ve sonuçları izlemeye devam ediyoruz.
07:00. API yüklemesiyle ilgili sorunlar
API'mizdeki yükü biraz yanlış planladığımız ve bu yükü test ettiğimiz, ancak sorunu tanımlayamadığımız açıkça ortaya çıkıyor. Sonuç olarak isteklerin ≈%5'i başarısız oluyor. Hadi harekete geçelim ve sebebini arayalım.
Faturalandırma inatçıdır ve çalışmak da istemez. Değişiklikleri sakin bir şekilde gerçekleştirmek için daha sonraya ertelemeye karar veriyoruz. Yani, tüm kaynaklar içinde birikir, ancak müşterilerden gelen zararlar geçmez. Elbette bu bir sorun, ancak genel kullanıma sunmayla karşılaştırıldığında önemsiz görünüyor.
08:00. API'yi düzelt
Yük için bir düzeltme yaptık, arızalar ortadan kalktı. Eve gitmeye başlıyoruz.
10:00. Tüm
Her şey sabittir. İzleme sırasında ortam sessizdir ve müşterilerin evinde ekip yavaş yavaş uykuya dalar. Fatura hala duruyor, yarın geri yükleyeceğiz.
Daha sonra gün içinde bazı müşterilerimiz için günlükleri, bildirimleri, dönüş kodlarını ve özelleştirmeleri düzelten sunumlar yapıldı.
Yani, kullanıma sunma başarılı oldu! Elbette daha iyi olabilirdi ama mükemmelliğe ulaşmamız için neyin yeterli olmadığı konusunda sonuçlar çıkardık.
Toplam
Kullanıma sunma için 2 ay süren aktif hazırlık sırasında, birkaç saatten birkaç güne kadar süren 43 görev tamamlandı.
Kullanıma sunma sırasında:
- yeni ve değiştirilmiş iblisler - 5 monolitin yerine 2 parça;
- veritabanlarındaki değişiklikler - kullanıcı verilerini içeren 6 veri tabanımızın tamamı etkilendi, üç eski veri tabanından yeni bir veri tabanına indirmeler yapıldı;
- tamamen yeniden tasarlanmış ön uç;
- indirilen kod miktarı - 33 bin satır yeni kod, testlerde ≈ 3 bin satır kod, ≈ 5 bin satır geçiş kodu;
- tüm veriler sağlamdır, tek bir müşterinin sanal makinesi bile zarar görmemiştir. 🙂
İyi kullanıma sunma için iyi uygulamalar
Bu zor durumda bize rehberlik ettiler. Ancak genel olarak konuşursak, herhangi bir kullanıma sunma sırasında bunları takip etmek faydalıdır. Ancak kullanıma sunma ne kadar karmaşık olursa, oynadıkları rol de o kadar büyük olur.
- Yapmanız gereken ilk şey, kullanıma sunmanın kullanıcıları nasıl etkileyebileceğini veya etkileyeceğini anlamaktır. Kesinti olacak mı? Eğer öyleyse, kesinti süresi nedir? Bu kullanıcıları nasıl etkileyecek? Olası en iyi ve en kötü durum senaryoları nelerdir? Ve riskleri örtün.
- Her şeyi planlayın. Her aşamada kullanıma sunmanın tüm yönlerini anlamanız gerekir:
- kod teslimi;
- kod geri alma;
- her operasyonun zamanı;
- etkilenen işlevsellik.
- Dağıtımın tüm aşamaları ve her birindeki riskler açıkça ortaya çıkana kadar senaryoları oynayın. Eğer şüpheniz varsa biraz ara verip şüpheli aşamayı ayrı ayrı inceleyebilirsiniz.
- Kullanıcılarımıza yardımcı olacaksa her aşama geliştirilebilir ve geliştirilmelidir. Örneğin, kesinti süresini azaltacak veya bazı riskleri ortadan kaldıracaktır.
- Geri alma testi, kod teslim testinden çok daha önemlidir. Geri alma işlemi sonucunda sistemin orijinal durumuna döneceğini kontrol etmek ve bunu testlerle doğrulamak gerekir.
- Otomatikleştirilebilen her şey otomatikleştirilmelidir. Otomatikleştirilemeyen her şey önceden bir kopya kağıdına yazılmalıdır.
- Başarı kriterini kaydedin. Hangi işlevsellik ne zaman mevcut olmalıdır? Bu gerçekleşmezse bir geri alma planı çalıştırın.
- Ve en önemlisi - insanlar. Herkes neyi, neden yaptığını ve kullanıma sunma sürecindeki eylemlerine neyin bağlı olduğunu bilmelidir.
Ve tek bir cümleyle, iyi bir planlama ve detaylandırmayla, satışları etkilemeden istediğiniz her şeyi hayata geçirebilirsiniz. Hatta üretimdeki tüm hizmetlerinizi etkileyecek bir şey.
Kaynak: habr.com