Bugün Bitrix24 hizmeti yüzlerce gigabit trafiğe sahip olmadığı gibi devasa bir sunucu filosuna da sahip değil (tabii ki mevcut çok sayıda sunucu olmasına rağmen). Ancak birçok müşteri için şirkette çalışmanın ana aracıdır; iş açısından kritik bir uygulamadır. Bu nedenle düşme gibi bir durum söz konusu değil. Peki ya çökme gerçekleşmişse ama hizmet o kadar çabuk "kurtarılmışsa" ve kimse bir şey fark etmemişse? Peki işin kalitesini ve müşteri sayısını kaybetmeden yük devretmeyi uygulamak nasıl mümkün olabilir? Bitrix24 bulut hizmetleri direktörü Alexander Demidov, blogumuz adına, ürünün 7 yıllık varlığı boyunca rezervasyon sisteminin nasıl geliştiğini anlattı.
“Bitrix24'ü 7 yıl önce SaaS olarak başlattık. Asıl zorluk muhtemelen şuydu: SaaS olarak halka açık olarak piyasaya sürülmeden önce, bu ürün sadece kutulu bir çözüm formatında mevcuttu. Müşteriler bunu bizden satın aldı, sunucularında barındırdı, kurumsal bir portal kurdu; çalışan iletişimi, dosya depolama, görev yönetimi, CRM için genel bir çözüm, hepsi bu. Ve 2012 yılına gelindiğinde bunu SaaS olarak başlatmaya, kendimiz yönetmeye, hata toleransı ve güvenilirliği sağlamaya karar verdik. Bu süreçte deneyim kazandık, çünkü o zamana kadar bu deneyime sahip değildik; biz yalnızca yazılım üreticisiydik, hizmet sağlayıcı değil.
Hizmeti başlatırken en önemli şeyin hata toleransını, güvenilirliği ve hizmetin sürekli kullanılabilirliğini sağlamak olduğunu anladık; çünkü basit, sıradan bir web siteniz, örneğin bir mağazanız varsa ve bu sizin üzerinize düşer ve orada kalır. bir saat, sadece siz acı çekersiniz, siparişleri kaybedersiniz, müşteri kaybedersiniz, ancak müşteriniz için bu onun için çok kritik değildir. Elbette üzüldü ama gidip başka bir siteden satın aldı. Ve eğer bu şirket içindeki tüm işlerin, iletişimin, kararların bağlı olduğu bir uygulama ise o zaman en önemli şey kullanıcıların güvenini kazanmak yani onları yarı yolda bırakmamak ve düşmemektir. Çünkü içeride bir şeyler çalışmazsa tüm işler durabilir.
Bitrix.24 SaaS olarak
İlk prototipi 2011 yılında halka açılmadan bir yıl önce monte ettik. Yaklaşık bir hafta içinde monte ettik, baktık, çevirdik, hatta çalışıyordu. Yani forma giriyorsunuz, oraya portalın adını giriyorsunuz, yeni bir portal açılıyor ve bir kullanıcı tabanı oluşuyor. Biz ona baktık, ürünü prensip olarak değerlendirdik, hurdaya çıkardık ve bir yıl boyunca geliştirmeye devam ettik. Çünkü büyük bir görevimiz vardı: İki farklı kod tabanı oluşturmak istemedik, ayrı bir paket ürünü, ayrı bulut çözümlerini desteklemek istemedik; hepsini tek bir kodda yapmak istedik.
O zamanlar tipik bir web uygulaması, üzerinde bazı PHP kodlarının çalıştığı, bir mysql veritabanının, dosyaların yüklendiği, belgelerin, resimlerin yükleme klasörüne yerleştirildiği bir sunucuydu - yani, hepsi çalışıyor. Ne yazık ki, bunu kullanarak kritik derecede kararlı bir web hizmeti başlatmak imkansızdır. Orada dağıtılmış önbellek desteklenmiyor, veritabanı çoğaltması desteklenmiyor.
Gereksinimleri formüle ettik: Bu, farklı konumlarda bulunma, çoğaltmayı destekleme ve ideal olarak coğrafi olarak dağıtılmış farklı veri merkezlerinde bulunma yeteneğidir. Ürün mantığını ve aslında veri depolamayı ayırın. Yüke göre dinamik olarak ölçeklenebilme ve statiği tamamen tolere edebilme. Aslında bu değerlendirmelerden, yıl boyunca geliştirdiğimiz ürüne yönelik gereksinimler ortaya çıktı. Bu süre zarfında, kutulu çözümler ve kendi hizmetimiz için birleşik hale gelen platformda ihtiyaç duyduğumuz şeyler için destek sağladık. Ürünün kendi düzeyinde MySQL çoğaltma desteği: yani kodu yazan geliştirici, isteklerinin nasıl dağıtılacağını düşünmez, bizim API'mizi kullanır ve yazma ve okuma isteklerinin ustalar arasında nasıl doğru şekilde dağıtılacağını biliyoruz. ve köleler.
Çeşitli bulut nesnesi depoları için ürün düzeyinde destek sağladık: Google depolama, Amazon s3 ve ayrıca Open Stack Swift desteği. Bu nedenle, bu hem hizmet olarak bizim için hem de paket çözümle çalışan geliştiriciler için uygun oldu: API'mizi yalnızca iş için kullanıyorlarsa, dosyanın sonuçta nereye kaydedileceğini, yerel olarak dosya sisteminde veya nesne dosyası deposunda.
Sonuç olarak hemen tüm veri merkezi seviyesinde rezervasyon yapmaya karar verdik. 2012 yılında tamamen Amazon AWS'de faaliyete geçtik çünkü bu platformda zaten deneyimimiz vardı; kendi web sitemiz orada barındırılıyordu. Amazon'un her bölgede çeşitli kullanılabilirlik bölgelerine sahip olması bizi cezbetti - aslında (terminolojilerine göre) birbirinden az çok bağımsız olan ve tüm veri merkezi düzeyinde rezervasyon yapmamıza izin veren birkaç veri merkezi: aniden arızalanırsa veritabanları ana-ana kopyalanır, web uygulaması sunucuları yedeklenir ve statik veriler s3 nesne deposuna taşınır. Yük dengelendi - o zamanlar Amazon elb tarafından, ancak kısa bir süre sonra kendi yük dengeleyicilerimize geldik çünkü daha karmaşık bir mantığa ihtiyacımız vardı.
İstedikleri, elde ettikleri oldu...
Sağlamak istediğimiz tüm temel şeyler (sunucuların hata toleransı, web uygulamaları, veritabanları) her şey iyi çalıştı. En basit senaryo: Web uygulamalarımızdan biri arızalanırsa her şey basittir; dengeleme kapatılır.
Dengeleyici (o zamanlar Amazon'un elb'iydi) arızalı makineleri sağlıksız olarak işaretledi ve üzerlerindeki yük dağıtımını kapattı. Amazon otomatik ölçeklendirme işe yaradı: yük arttığında, otomatik ölçeklendirme grubuna yeni makineler eklendi, yük yeni makinelere dağıtıldı - her şey yolundaydı. Dengeleyicilerimizde mantık hemen hemen aynı: Uygulama sunucusuna bir şey olursa, ondan istekleri kaldırırız, bu makineleri atarız, yenilerini başlatırız ve çalışmaya devam ederiz. Plan yıllar içinde biraz değişti ama çalışmaya devam ediyor: basit, anlaşılır ve bunda hiçbir zorluk yok.
Dünyanın her yerinde çalışıyoruz, müşteri yük yoğunlukları tamamen farklıdır ve dostane bir şekilde, sistemimizin herhangi bir bileşeni üzerinde belirli servis çalışmalarını müşterilerimiz tarafından fark edilmeden herhangi bir zamanda gerçekleştirebilmeliyiz. Bu nedenle, yükü ikinci bir veri merkezine yeniden dağıtarak veritabanını çalışmadan kapatma fırsatımız var.
Her şey nasıl çalışıyor? — Trafiği çalışan bir veri merkezine aktarıyoruz - eğer veri merkezinde bir kaza olursa, o zaman tamamen, tek bir veritabanıyla planladığımız çalışma buysa, bu müşterilere hizmet veren trafiğin bir kısmını ikinci bir veri merkezine geçirerek askıya alırız bu çoğaltmadır. İkinci veri merkezinin yükünün artması nedeniyle web uygulamaları için yeni makinelere ihtiyaç duyulursa bunlar otomatik olarak başlayacaktır. İşi bitiriyoruz, çoğaltma geri yükleniyor ve yükün tamamını geri döndürüyoruz. İkinci DC'de bazı işleri yansıtmamız gerekirse, örneğin sistem güncellemelerini yüklememiz veya ikinci veritabanındaki ayarları değiştirmemiz gerekiyorsa, o zaman genel olarak aynı şeyi tam tersi yönde tekrarlarız. Ve eğer bu bir kazaysa, o zaman her şeyi önemsizce yaparız: izleme sistemindeki olay giderici mekanizmasını kullanırız. Birkaç kontrol tetiklenirse ve durum kritik hale gelirse, o zaman şu veya bu mantığı yürütebilecek bir işleyici olan bu işleyiciyi çalıştırırız. Her veritabanı için, hangi sunucunun yük devretme olduğunu ve kullanılamıyorsa trafiğin nereye değiştirilmesi gerektiğini belirtiriz. Tarihsel olarak, nagios'u veya çatallarından bazılarını şu veya bu şekilde kullanırız. Prensip olarak, hemen hemen her izleme sisteminde benzer mekanizmalar mevcuttur; henüz daha karmaşık bir şey kullanmıyoruz, ancak belki bir gün kullanacağız. Artık izleme, kullanılamama nedeniyle tetikleniyor ve bir şeyi değiştirme olanağına sahip.
Herşeyi ayırttık mı?
ABD'den birçok müşterimiz var, Avrupa'dan birçok müşterimiz var, Doğu'ya daha yakın olan Japonya, Singapur vb. birçok müşterimiz var. Tabii ki müşterilerin büyük bir kısmı Rusya'da. Yani iş tek bir bölgede olmuyor. Kullanıcılar hızlı yanıt istiyor, çeşitli yerel yasalara uyma gereklilikleri var ve her bölge içinde iki veri merkezi ayırıyoruz, ayrıca aynı bölgede bulunan müşteriler için yine tek bir bölgeye yerleştirilmesi uygun olan bazı ek hizmetler de var. bu bölge çalışıyor. REST işleyicileri, yetkilendirme sunucuları, bir bütün olarak istemcinin çalışması için daha az kritiktirler, kabul edilebilir küçük bir gecikmeyle bunlar arasında geçiş yapabilirsiniz, ancak bunların nasıl izleneceği ve ne yapılacağı konusunda tekerleği yeniden icat etmek istemezsiniz. onlarla. Bu nedenle ek ürünlerde bir çeşit yetkinlik geliştirmek yerine, mevcut çözümlerden maksimum düzeyde yararlanmaya çalışıyoruz. Ve bir yerde DNS düzeyinde geçiş yapmayı önemsiz bir şekilde kullanıyoruz ve hizmetin canlılığını aynı DNS ile belirliyoruz. Amazon'un Route 53 hizmeti var, ancak bu yalnızca giriş yapabileceğiniz bir DNS değil, hepsi bu; çok daha esnek ve kullanışlı. Bu sayede, müşterinin nereden geldiğini belirlemek ve ona belirli kayıtları vermek için kullandığınızda, coğrafi konumlara sahip coğrafi olarak dağıtılmış hizmetler oluşturabilirsiniz - onun yardımıyla yük devretme mimarileri oluşturabilirsiniz. Aynı sağlık kontrolleri Route 53'ün kendisinde de yapılandırılmıştır; izlenen uç noktaları siz belirlersiniz, ölçümleri belirlersiniz, hizmetin "canlılığını" hangi protokollerin belirleyeceğini belirlersiniz - tcp, http, https; Hizmetin canlı olup olmadığını belirleyen kontrollerin sıklığını ayarlayın. Ve DNS'nin kendisinde, neyin birincil olacağını, neyin ikincil olacağını, eğer durum kontrolü rota 53'te tetiklenirse nereye geçileceğini belirtirsiniz. Tüm bunlar başka bazı araçlarla yapılabilir, ancak neden uygun - biz ayarladık bir kez açtığınızda, kontrolleri nasıl yaptığımızı, nasıl geçiş yaptığımızı hiç düşünmeyin: her şey kendi kendine çalışır.
İlk "ama": 53. güzergahın kendisi nasıl ve neyle rezerve edilir? Kim bilir, ya başına bir şey gelirse? Neyse ki bu tırmığa hiç basmadık ama yine de neden hala rezervasyon yaptırmamız gerektiğini düşündüğümüze dair bir hikayem olacak. Burada önceden kendimiz için pipetler hazırladık. Günde birkaç kez rota 53'teki tüm bölgeleri tamamen boşaltıyoruz. Amazon'un API'si bunları kolayca JSON olarak göndermenize olanak tanır ve bunları dönüştürdüğümüz, yapılandırma biçiminde yüklediğimiz ve kabaca söylemek gerekirse bir yedekleme yapılandırmasına sahip olduğumuz birkaç yedekleme sunucumuz var. Bir şey olursa, DNS ayarları verilerini kaybetmeden bunu hızlı bir şekilde manuel olarak dağıtabiliriz.
İkinci "ama": Bu resimde henüz rezerve edilmemiş olan ne var? Dengeleyicinin kendisi! Müşterilerin bölgelere göre dağıtımımız çok basit hale getirildi. Bitrix24.ru, bitrix24.com, .de alan adlarına sahibiz; şimdi çeşitli bölgelerde faaliyet gösteren 13 farklı alan var. Şu noktaya geldik: Her bölgenin kendi dengeleyicileri var. Bu, ağdaki en yüksek yükün nerede olduğuna bağlı olarak bölgeler arasında dağıtımı daha kolay hale getirir. Bu, tek bir dengeleyici düzeyinde bir arıza ise, o zaman hizmet dışı bırakılır ve dns'den kaldırılır. Bir grup dengeleyicide sorun olması durumunda, bunlar başka sitelere yedeklenir ve aralarında geçiş aynı rota53 kullanılarak yapılır, çünkü kısa TTL nedeniyle geçiş maksimum 2, 3, 5 dakika içinde gerçekleşir. .
Üçüncü "ama": Henüz rezerve edilmemiş olan nedir? S3, doğru. Kullanıcılar için sakladığımız dosyaları s3'e yerleştirdiğimizde bunun zırh delici olduğuna gerçekten inandık ve orada hiçbir şey ayırmaya gerek yoktu. Ancak tarih olayların farklı olduğunu gösteriyor. Amazon genel olarak S3'ü temel bir hizmet olarak tanımlıyor çünkü Amazon'un kendisi makine görüntülerini, yapılandırmaları, AMI görüntülerini, anlık görüntüleri depolamak için S3'ü kullanıyor... Ve eğer s3, biz kullandığımız sürece, bu 7 yılda bir kez olduğu gibi çökerse, bitrix24, onu bir hayran gibi takip ediyor Ortaya çıkan bir sürü şey var: sanal makinelerin başlatılamaması, API hatası vb.
Ve S3 düşebilir; bu bir kez oldu. Bu nedenle şu şemaya vardık: Birkaç yıl önce Rusya'da ciddi bir kamu nesne depolama tesisi yoktu ve kendi başımıza bir şeyler yapma seçeneğini düşündük... Neyse ki bunu yapmaya başlamadık çünkü sahip olmadığımız uzmanlığı araştırdık ve muhtemelen işleri berbat ederiz. Artık Mail.ru'da s3 uyumlu depolama alanı var, Yandex'de var ve diğer bazı sağlayıcılarda da var. Sonunda, öncelikle yedeklemeye, ikinci olarak da yerel kopyalarla çalışabilme yeteneğine sahip olmak istediğimiz fikrine vardık. Özellikle Rusya bölgesi için s3 ile API uyumlu Mail.ru Hotbox hizmetini kullanıyoruz. Uygulamanın içindeki kodda büyük bir değişikliğe ihtiyacımız olmadı ve şu mekanizmayı yaptık: s3'te nesnelerin oluşturulmasını/silinmesini tetikleyen tetikleyiciler var, Amazon'un Lambda adında bir hizmeti var - bu, kodun sunucusuz başlatılmasıdır Bu, yalnızca belirli tetikleyiciler tetiklendiğinde yürütülecektir.
Bunu çok basit bir şekilde yaptık: Tetikleyicimiz etkinleşirse, nesneyi Mail.ru depolama alanına kopyalayacak kodu çalıştırırız. Yerel veri kopyalarıyla çalışmayı tam olarak başlatmak için, Rusya segmentindeki müşterilerin kendilerine daha yakın depolamayla çalışabilmesi için ters senkronizasyona da ihtiyacımız var. Mail, deposundaki tetikleyicileri tamamlamak üzere - altyapı düzeyinde ters senkronizasyon yapmak mümkün olacak, ancak şimdilik bunu kendi kodumuz düzeyinde yapıyoruz. Bir istemcinin bir dosya gönderdiğini görürsek, kod düzeyinde olayı kuyruğa alır, işler ve ters çoğaltma yaparız. Neden kötü: Ürünümüzün dışında, yani dışsal yollarla objelerimizle bir tür çalışma yaparsak, bunu hesaba katmayız. Bu nedenle, depolama düzeyinde tetikleyiciler görünene kadar sonuna kadar bekleriz, böylece kodu nereden çalıştırırsak çalıştıralım, bize gelen nesne diğer yönde kopyalanır.
Kod düzeyinde, her istemci için her iki depolamayı da kaydederiz: biri ana depo, diğeri yedek depo olarak kabul edilir. Her şey yolundaysa, bize daha yakın olan depolama ile çalışıyoruz: yani Amazon'da bulunan müşterilerimiz S3 ile, Rusya'da çalışanlar ise Hotbox ile çalışıyorlar. Bayrak tetiklenirse yük devretme bağlanmalıdır ve istemcileri başka bir depolama birimine geçiririz. Bu kutuyu bölgeye göre bağımsız olarak işaretleyebilir ve bunları ileri geri değiştirebiliriz. Bunu henüz pratikte kullanmadık ama bu mekanizmayı sağladık ve bir gün bu anahtara ihtiyacımız olacağını ve işe yarayacağını düşünüyoruz. Bu zaten bir kez oldu.
Ah, Amazon kaçtı...
Bu Nisan, Rusya'da Telegram engellemesinin başlangıcının yıldönümünü kutluyor. Bunun kapsamına giren en çok etkilenen sağlayıcı Amazon'dur. Ve ne yazık ki tüm dünya için çalışan Rus şirketleri daha çok zarar gördü.
Şirket küreselse ve Rusya onun için çok küçük bir segmentse, %3-5 - öyle ya da böyle onları feda edebilirsiniz.
Bu tamamen bir Rus şirketiyse - yerel olarak konumlandırılması gerektiğinden eminim - kullanıcılar için uygun, rahat olacak ve daha az risk olacaktır.
Peki ya bu, dünya çapında faaliyet gösteren ve Rusya'dan ve dünyanın herhangi bir yerinden yaklaşık olarak eşit sayıda müşteriye sahip bir şirketse? Segmentlerin bağlantısı önemlidir ve bir şekilde birbirleriyle çalışmaları gerekir.
Mart 2018'in sonunda Roskomnadzor, en büyük operatörlere Zello messenger'ı engellemek için birkaç milyon Amazon IP'sini engellemeyi planladıklarını belirten bir mektup gönderdi. Aynı sağlayıcılar sayesinde mektubu başarıyla herkese sızdırdılar ve Amazon ile bağlantının kopabileceğine dair bir anlayış vardı. Cuma günüydü, panik içindeservers.ru'dan meslektaşlarımıza şu sözlerle koştuk: "Arkadaşlar, Rusya'da, Amazon'da değil, örneğin Amsterdam'da bir yerde bulunacak birkaç sunucuya ihtiyacımız var." hiçbir şekilde etkileyemediğimiz bazı uç noktalar için, örneğin aynı s3'ün uç noktaları için en azından bir şekilde kendi VPN'imizi ve proxy'mizi kurabilmek için - yeni bir hizmet yükseltmeye ve farklı bir hizmet almaya çalışamayız ip, hala oraya gitmemiz gerekiyor. Sadece birkaç gün içinde bu sunucuları kurduk, çalışır hale getirdik ve genel olarak engellemenin başlayacağı ana hazırlandık. Yaygara ve paniğe bakan RKN'nin şunu söylemesi ilginç: "Hayır, artık hiçbir şeyi engellemeyeceğiz." (Ancak bu tam olarak Telegram'ın engellenmeye başladığı ana kadardı.) Baypas yeteneklerini ayarladıktan ve engellemenin getirilmediğini fark ettikten sonra, tüm konuyu çözmeye başlamadık. Evet, her ihtimale karşı.
Ve şimdi 2019'da hâlâ engelleme koşullarında yaşıyoruz. Dün gece baktım: yaklaşık bir milyon IP hâlâ engellenmeye devam ediyor. Doğru, Amazon'un engeli neredeyse tamamen kaldırılmıştı, zirve noktasında 20 milyon adrese ulaşmıştı... Genel olarak gerçek şu ki, tutarlılık olmayabilir, iyi bir tutarlılık. Birden. Teknik nedenlerden dolayı mevcut olmayabilir; yangınlar, ekskavatörler, hepsi. Veya gördüğümüz gibi tamamen teknik değil. Bu nedenle, kendi AS'leri olan büyük ve büyük biri bunu muhtemelen başka yollarla yönetebilir - doğrudan bağlantı ve diğer şeyler zaten l2 düzeyindedir. Ancak bizimki gibi basit bir versiyonda, hatta daha küçük bir versiyonda, her ihtimale karşı, başka bir yerde yükseltilmiş sunucular düzeyinde, önceden yapılandırılmış vpn, proxy ve bu segmentlerdeki yapılandırmayı hızlı bir şekilde onlara geçirme yeteneği ile yedekliliğe sahip olabilirsiniz. bunlar bağlantınız için kritik öneme sahiptir. Bu bizim için birden fazla kez işe yaradı; en kötü senaryoda Amazon'un engellemesi başladığında yalnızca S3 trafiğine izin verdik, ancak yavaş yavaş tüm bunlar çözüldü.
Bir sağlayıcının tamamı nasıl rezerve edilir?
Şu anda Amazon'un tamamının çökmesi ihtimaline karşı bir senaryomuz yok. Rusya için de benzer bir senaryomuz var. Rusya'da, birden fazla siteye sahip olmayı seçtiğimiz bir sağlayıcı tarafından barındırıldık. Ve bir yıl önce bir sorunla karşılaştık: Bunlar iki veri merkezi olmasına rağmen, sağlayıcının ağ yapılandırması düzeyinde her iki veri merkezini de etkileyecek sorunlar zaten olabilir. Ve her iki sitede de kullanılamayabiliriz. Elbette öyle oldu. İçerideki mimariyi yeniden değerlendirdik. Çok fazla değişmedi ama Rusya için artık aynı sağlayıcıdan değil iki farklı siteden iki sitemiz var. Biri başarısız olursa diğerine geçebiliriz.
Varsayımsal olarak Amazon için başka bir sağlayıcı düzeyinde rezervasyon olasılığını düşünüyoruz; belki Google, belki bir başkası... Ancak şu ana kadar pratikte gözlemledik ki, Amazon'un bir erişilebilirlik bölgesi düzeyinde kazaları varken, tüm bölge düzeyindeki kazaların oldukça nadir olduğu görülüyor. Dolayısıyla teorik olarak “Amazon Amazon değildir” rezervasyonu yaparız gibi bir düşüncemiz var ancak pratikte henüz böyle bir durum söz konusu değil.
Otomasyon hakkında birkaç kelime
Otomasyon her zaman gerekli midir? Burada Dunning-Kruger etkisini hatırlamakta fayda var. “X” ekseninde edindiğimiz bilgi ve deneyimler, “y” ekseninde ise eylemlerimize olan güven yer alıyor. İlk başta hiçbir şey bilmiyoruz ve kesinlikle emin değiliz. O zaman biraz biliriz ve kendimize çok güveniriz - bu, "demans ve cesaret" resmiyle iyi bir şekilde gösterilen, "aptallığın zirvesi" olarak adlandırılan durumdur. Sonra biraz öğrendik ve savaşa girmeye hazırız. Sonra çok ciddi hatalara basarız ve bir şeyi biliyor gibi görünsek de aslında pek bir şey bilmediğimiz bir anda kendimizi bir umutsuzluk vadisinde buluruz. Daha sonra deneyim kazandıkça kendimize daha çok güveniyoruz.
Belirli kazalara yönelik çeşitli otomatik geçişler hakkındaki mantığımız bu grafikte çok iyi açıklanmaktadır. Başladık - hiçbir şeyi nasıl yapacağımızı bilmiyorduk, neredeyse tüm iş elle yapıldı. Sonra her şeye otomasyon bağlayabileceğimizi ve huzur içinde uyuyabileceğimizi fark ettik. Ve aniden büyük bir komisyona basıyoruz: yanlış bir pozitif tetikleniyor ve iyi anlamda bunu yapmamamız gerekirken trafiği ileri geri değiştiriyoruz. Sonuç olarak kopyalama bozulur veya başka bir şey olur; bu tam da umutsuzluk vadisidir. Ve sonra her şeye akıllıca yaklaşmamız gerektiğini anlıyoruz. Yani, yanlış alarm olasılığını sağlayan otomasyona güvenmek mantıklıdır. Ancak! eğer sonuçları yıkıcı olabiliyorsa, o zaman işi nöbetçi mühendislere bırakmak, gerçekten bir kaza olup olmadığını kontrol edecek ve gerekli işlemleri manuel olarak yapacak olan mühendislere bırakmak daha iyidir...
Sonuç
7 yıl boyunca, bir şey düştüğünde panik-panik yaşandığı gerçeğinden, sorunların var olmadığı, yalnızca görevler olduğu, bunların çözülmesi gerektiği ve çözülebileceği anlayışına geçtik. Bir hizmeti inşa ederken ona yukarıdan bakın, olabilecek tüm riskleri değerlendirin. Bunları hemen görürseniz, yedekliği ve hataya dayanıklı bir altyapı oluşturma olasılığını önceden sağlayın, çünkü başarısız olabilecek ve hizmetin çalışamaz hale gelmesine yol açabilecek herhangi bir nokta kesinlikle bunu yapacaktır. Ve size s3 gibi bazı altyapı öğelerinin kesinlikle başarısız olmayacağı gibi görünse bile, yine de yapabileceklerini unutmayın. Ve en azından teoride, bir şey olursa onlarla ne yapacağınıza dair bir fikriniz olsun. Bir risk yönetim planınız olsun. Her şeyi otomatik veya manuel yapmayı düşündüğünüzde riskleri değerlendirin: Otomasyon her şeyi değiştirmeye başlarsa ne olur? Bu, kazayla karşılaştırıldığında daha da kötü bir duruma yol açmaz mı? Belki bir yerlerde, otomasyonun kullanımı ile gerçek tabloyu değerlendirecek ve bir şeyin anında değiştirilmesi gerekip gerekmediğini veya "evet, ama şimdi değil" olup olmadığını anlayacak olan görevdeki mühendisin tepkisi arasında makul bir uzlaşmanın kullanılması gerekebilir.
Mükemmeliyetçilik ile sonunda sahip olacağınız plan üzerinde harcayabileceğiniz gerçek çaba, zaman ve para arasında makul bir uzlaşma.
Bu metin Alexander Demidov’un konferanstaki raporunun güncellenmiş ve genişletilmiş versiyonudur. .
Kaynak: habr.com