Neden web siteleri (bu bile olsa) bazen “Bakım için Aşağı”?

Ben şahsen bunu hiç yapmadım. Neden bu kadar çok sitenin yaptığını anlamıyorum, bir geliştirme sunucusunda geliştirmenizi yaparsanız, neden üretim sitenizi kapatmaya ihtiyacınız olacak?

Bunu hep merak etmişimdir.

Bu sırada ne yapıyorlar, bunu yapmak için ne gerekiyor?

Büyük ölçekli herhangi bir şey için büyük vurucu, eğer biri bir şekilde veritabanı şemalarını değiştiriyorsa, çalıştırılacak bazı büyük, kötü bakım komut dosyalarına sahip olmasıdır.

Şimdi, bunların gelişim veri kümenizle birlikte çalışması bir saniye kadar sürebilir. Ancak, terabayt ve petabayt cinsinden veri ölçmeye başladığınızda, bir tabloya tek bir sütun eklemek bile saatlerce sürebilir.

Dağıtım ne kadar hızlı ve otomatik olursa olsun, gerçekleştirmeniz gereken veri bakımı konularında hala sorunlarınız var. Gerçekten iyi planlıyorsanız, işlem sırasında sitenin salt okunur bir aynasını oluşturabilirsiniz, ancak çoğu site için salt okunur anlamsızdır ve bu nedenle çabaya değmez.

Bir siteyi bakım amacıyla kullanmanızın çeşitli nedenleri olabilir. Birkaç isim:

• Veri tabanı değişiklikleri
• DAL değişiklikleri
• Güncelleme hizmetleri

Temel olarak, siteniz statik değilse, bir mantıksal güncelleme yaparken aşağı çekmek istiyorsunuz, aksi halde sitenizi vuran insanlar hata veya beklenmeyen davranışlar alabilir.

Ayrıca, siteniz için web.config'e (ASP.NET'te) dokunacaksanız, kullanıcılar için oturumu sonlandıracağı için bakım için kullanmanız gerekir. Böylece, eğer bir şeyin ortasında olsaydı, kaybolurdu.

Bu bir şekilde soyut bir sorudur - HTTP 500 yerine "Down for Maintenance" kullanan siteler bile gördüm.

Web siteleri için bazen biraz yükseltme yapmanız gerekir. Örneğin, veritabanını değiştiriyorsanız, bu süre zarfında başka bir kullanıcının veritabanına dokunmasını istemezsiniz. Eğer veritabanı çevrimdışıysa, SqlException gösterilmesi çok iyi olmadığından, sitenin dikkatlice kapatılması gerekir. Başka bir neden, uygulama veya hatta sistemin yeniden başlatılmasını gerektiren bazı HW arızaları veya sistem arızalarıdır (sızıntı yapan kaynaklar gibi).

Bir keresinde ülkemdeki en büyük bankalardan birinde internet bankacılığı sisteminin geliştirilmesine katıldım. Web sitelerinin, orta katmanların ve veritabanlarının güncellenmesi sürecinin, sistemin müşteriler için çevrimdışı olduğu üç gün sürdü. Aynı zamanda her şeyin tam yedeklemesini içeriyordu, bu nedenle arıza durumunda sistem eski sürüme geri döndürülebiliyordu.

Sunucuların çalışması için düzeltme eklerine ihtiyaç vardır ve birçok işletim sisteminde bu düzeltme eklerinin yeniden başlatılması gerekir. Demek ki zaman aşımının bir kategorisi. Pek çok şirket, pazar sabahı gibi düşük kullanım süreleri için yamalardan yeniden başlatma programlamaktadır. Herhangi bir yama yoksa, sunucuları düzenli aralıklarla planlanan bakım zamanında yine de yeniden başlatırlar (bu, belirli sayaçların her hafta ve bir buçuk ayda bir taşması nedeniyle NT4 gününden bir akşamdan kalmadır, bu nedenle haftalık yeniden başlatma diğer hataları önler).

Çalıştığım şirketlerden biri, 90'ların sonunda aylık 1.000.000 dolardan fazla satış getiren bir e-ticaret sitesine sahipti. Birisi yanlış vergi tablosunu üretim veritabanı sunucusuna terfi ettirdi. Buradaki tedavi db sunucusunu yedekten geri yüklemek ve işlemleri son yedekten beri uygulamaktı. Bu işlem birkaç saat sürdü, bu sırada web sitesi sipariş almak için uygun değildi. Siparişler bölümü ve statik satış broşürleri aynı sitede çalıştığından ve birbirinden ayrılmaz olduğu için her ikisinin de düşmesi gerekiyordu.

Çalıştığım bir şirket yanlış yere bazı yanlış metinler yerleştirdi ve CEO düzene girdi ve metin "düzeltildi" ve uygun kurban suçlup kovulurken web sitesi "bakım" için kapatıldı.

Diğer cevaplar doğru olsa da, doğru mimarileri kullanarak çalışmama süresinden hemen hemen kaçınılabilirsiniz. Fakat bunun bir bedeli var ve bu bedeli buna değmeyebilir: bir saatlik aksama süresi amazon veya NASDAQ'ın arkasındaki altyapının maliyeti. Stackoverflow? Büyük olasılıkla pek değil.

Arıza süreleri nasıl önlenir:

• donanım sunma sayfalarını kapatma: web sitenizin önünde proxy'ler varsa, bunun yerine kullanıcıyı etkilemeden çevrimdışı duruma getirebilirsiniz
• sunucuları yeniden yapılandırma: yukarıdakiyle aynı
• Veritabanlarındaki verileri güncelleme / değiştirme: web sitenizi salt okunur moda sokabilirsiniz, vb.

Genel olarak, katmanlı bir mimaride, "üst" e yaklaştıkça, duruş süresinden kaçınmak en zor olan durumdur, durum bilgisi için aynıdır (web sunucusu vs veritabanı).

Bir site, planlanan kapalı kalma süresinin her geldiğinde yapılacak bir şey olmasa da, normal kapalı kalma süresi planlayabilir. Böyle yaparak, onlar site çalışması yaparken sık sık bu yüzden o zaman belirli bir miktar için kapanacak fikrine kullanılan kullanıcıları almak yapar ihtiyaç yapılması gereken, kullanıcıların çok şikayet olmaz.

Ayrıca bunun psikolojik ve pazarlama bir yanı var. Bazı durumlarda (vakaların çoğunu söylemeye cesaret ediyorum ama cesur değilim * g *) "Bakım için aşağı" yı okumak, "Sunucu başka bir nedenden dolayı çöktü veya hizmet dışı kaldı" anlamına da gelebilir.

Bunu oldukça sık gördüm. Normalde bir geliştirici olarak "Boğmaca, şu anda yüksek bir yük yaşıyoruz ve tüm isteklerin yerine getirilemeyeceğini" söyleyen "gerçek" bir hata mesajı isteyeceksiniz, ancak pazarlamadan bazı insanlar size "ahbap, Müşteriye sorun yaşadığımızı söyleyin. Onlara planlı bakımda olduğumuzu söyleyin - bu daha iyi görünecektir ".

Yani "bakım için aşağı" genellikle "hizmet dışı" için sadece başka bir terimdir.

Hiçbir sunucu bakım için aşağıya ihtiyaç duymaz. Herhangi bir ölçekte, herhangi bir ölçekte, DB değişikliğinde, sunucu güncellemelerinde vb. Yapmaktan kaçınabilirsiniz.

Sorun şu ki, kesinti süresi olmayan bir sistemin belirli bir ölçekte oluşturması ve sürdürmesi çok maliyetli. Her yerde yedeklilik, her yerde yük dengeleme, veri çoğaltma, senkronizasyon gerekiyor. Bunlar zor problemler.

Temel olarak, Netflix Chaos Monkey'i sisteminizin bir parçası güncellemeyle meşgul olsa veya sadece senkronizasyon dışı olsa bile çalıştığından emin olmak için prod içinde serbest bırakma seviyesine ulaşmanız gerekir. Bu kesinlikle yapılabilir. Aynı zamanda çok pahalıdır, çok fazla zaman gerektirir ve bu konuda çalışmak için birçok uzmana ihtiyaç duyar.

Bir siteyi bakım moduna geçirmek, seçtiğiniz bir orta yol olabilir, çünkü sitenizi arada bir süre için kullanmayacağınız için yatırım yapmak istemezsiniz.

Ekonomi.

Tabii ki, 0 iniş zamanı yolunu seçerseniz, siteniz uygunluktan fazlasını kazanacak, güvenilirliği de kazanacaktır, çünkü bu en iyi uygulamalar her iki amaca da hizmet eder.

Neden bu kadar çok sitenin yaptığını anlamıyorum, bir geliştirme sunucusunda geliştirmenizi yaparsanız, neden üretim sitenizi kapatmaya ihtiyacınız olacak?

Kahretsin olur. Teslim edilebilirlerinizin ( ve şartnamenizin geçerli olduğu ) bir miktar matematiksel doğrulama yapmıyorsanız , ne kadar dikkatli olursanız olun, her şey olur.

Ayrıca, altyapınızın temel bir parçası üzerinde değişiklik yapmak zorunda kalabileceğiniz (örneğin, veritabanı yapılarınızdaki bir değişiklik) zaman aşımı gerektiren zamanlar olabilir.

Kritik bir sistem geliştirmiyorsanız ( beş-dokuz veya altı dokuz sistemi söyleyin ), yapılacak sorumlu ve maliyet-etkin şey, çalışma zamanını gerçekliğin bir parçası olarak kabul eden bir sistem oluşturmaktır.

Ayrıca, etkili bir iyileşme için açık bir anlayış ve prosedürle zamanları yönetilebilir ve programlamaya uygun (veya en azından tespit edilebilir) hale getirerek bu ilkeyi daha da ileri götürürsünüz.

Web sitemiz saldırıya uğradıktan sonra (eski IIS6 ve Windows 2003 sunucusu birkaç yıl önce). restorasyon üzerinde çalışırken birkaç saatliğine "bakım altında" sayfasını yerleştirdik ....