Herkese mutlu cumalar! Arkadaşlar bugün derse adanmış yayın serisine devam ediyoruz. Çünkü kurs için yeni gruptaki dersler önümüzdeki hafta sonunda başlayacak. Öyleyse başlayalım!
İzleme: sadece. Bu bilinen bir gerçektir. Nagios'u açın, uzaktaki sistemde NRPE'yi çalıştırın, Nagios'u NRPE TCP bağlantı noktası 5666'da yapılandırın ve izleme işlemine başlayın.
O kadar kolay ki ilginç değil. Artık Nagios ve NRPE'ye varsayılan olarak sağlanan CPU zamanı, disk alt sistemi ve RAM için temel ölçümlere sahipsiniz. Ama bu aslında tam anlamıyla bir “izleme” değil. Bu sadece başlangıç.
(Genellikle PNP4Nagios, RRDtool ve Thruk'u yüklerler, Slack'te bildirimleri ayarlarlar ve doğrudan nagiosexchange'e giderler, ancak şimdilik bunu dışarıda bırakalım).
İyi izleme aslında oldukça karmaşık, izlediğiniz uygulamanın içini gerçekten bilmeniz gerekiyor.
İzleme zor mu?
Herhangi bir sunucu, ister Linux ister Windows olsun, tanımı gereği bir amaca hizmet edecektir. Apache, Samba, Tomcat, dosya depolama, LDAP - tüm bu hizmetler bir veya daha fazla açıdan aşağı yukarı benzersizdir. Her birinin kendi işlevi, kendine has özellikleri vardır. Sunucu yük altındayken ilginizi çeken ölçümleri, KPI'leri (temel performans göstergeleri) almanın farklı yolları vardır.
fotoğrafı çeken üzerinde
(Keşke kontrol panellerim neon mavisi olsaydı - rüya gibi iç çekiyorum -... hmm...)
Hizmet sağlayan herhangi bir yazılımın metrikleri toplayacak bir mekanizmaya sahip olması gerekir. Apache'nin bir modülü var mod-status, sunucu durumu sayfasını görüntüler. Nginx'te - stub_status. Tomcat'in önemli ölçümleri gösteren JMX veya özel web uygulamaları vardır. MySQL'in "global durumu göster" vb. bir komutu vardır.
Peki geliştiriciler neden oluşturdukları uygulamalara benzer mekanizmalar kurmuyor?
Bunu sadece geliştiriciler mi yapıyor?
Metrik yerleştirmeye belirli düzeyde bir kayıtsızlık geliştiricilerle sınırlı değildir. Tomcat'i kullanarak uygulamalar geliştirdikleri ve genel Tomcat hata günlükleri dışında kendi metriklerinden herhangi birini, hizmet etkinliği günlüklerini sağlamadıkları şirketlerde çalıştım. Bazı geliştiriciler, sabahın 3:15'inde bunları okuyacak kadar şanssız olan sistem yöneticisi için hiçbir şey ifade etmeyen çok sayıda günlük oluşturur.
fotoğrafı çeken üzerinde
Bu tür ürünlerin piyasaya sürülmesini sağlayan sistem mühendislerinin de bu durumun bir miktar sorumluluğunu üstlenmesi gerekiyor. Çok az sistem mühendisinin, bu metriklerin bağlamı ve bunları uygulama etkinliği ışığında yorumlama yeteneği olmadan, günlüklerden anlamlı metrikler çıkarmaya çalışacak zamanı veya özeni vardır. Bazıları, "şu anda bir şeylerin yanlış olduğu (veya yakında yanlış olacağı)" göstergeleri dışında bundan nasıl yararlanabileceklerini anlamıyor.
Metrik ihtiyacına ilişkin düşünce değişikliği yalnızca geliştiriciler arasında değil aynı zamanda sistem mühendisleri arasında da gerçekleşmelidir.
Yalnızca kritik olaylara yanıt vermekle kalmayıp aynı zamanda bu olayların gerçekleşmemesini de sağlamak isteyen herhangi bir sistem mühendisi için ölçüm eksikliği genellikle bunu yapmanın önünde bir engeldir.
Ancak sistem mühendisleri genellikle şirketlerine para kazandırmak için kodla uğraşmazlar. Sorunları belirleme, performans sorunlarına ilişkin farkındalığı artırma ve benzeri konularda sistem mühendisinin sorumluluğunun önemini anlayan lider geliştiricilere ihtiyaçları var.
Bu şey yok ediyor
Devops zihniyeti, geliştirme (dev) ve operasyon (ops) düşüncesi arasındaki sinerjiyi tanımlar. "Devops yaptığını" iddia eden herhangi bir şirketin:
- muhtemelen söylemedikleri şeyleri söylemek (Prenses Gelin meme'ine atıfta bulunarak - "Bunun sizin düşündüğünüz anlama geldiğini sanmıyorum!")
- Sürekli ürün iyileştirme tutumunu teşvik edin.
Şu anda nasıl çalıştığını bilmiyorsanız, bir ürünü iyileştiremezsiniz ve geliştirildiğini bilemezsiniz. Bileşenlerinin nasıl çalıştığını, bağlı olduğu hizmetleri, ana sorun noktalarını ve darboğazlarını anlamazsanız bir ürünün nasıl çalıştığını bilemezsiniz.
Potansiyel darboğazlara dikkat etmezseniz, Ölüm Sonrası yazarken Beş Neden tekniğini takip edemezsiniz. Bir ürünün nasıl çalıştığını görmek veya "normal ve mutlu" neye benzediğini bilmek için her şeyi tek bir ekrana koyamazsınız.
Sola kaydır, SOL, LEEEE DEDİM—
Benim için Devops'un temel ilkelerinden biri "sola kaydırma"dır. Bu bağlamda sola kaydırma, olasılığı kaydırmak anlamına gelir (sorumluluk almamak, ancak yalnızca yetenekler) Yazılım Teslimatı Yaşam Döngüsünün solunda performans ölçümleri oluşturmak, günlükleri daha verimli kullanmak vb. gibi sistem mühendislerinin genellikle önemsediği şeyleri yapmak için kullanılır.
fotoğrafı çeken üzerinde
Yazılım geliştiricileri, şirketin tüm formlarında, metriklerinde, loglamalarında, izleme arayüzlerinde ve en önemlisi izleme işlemlerini gerçekleştirmek için kullandığı izleme araçlarını kullanabilmeli ve bilmelidir. ürünlerinin üretimde nasıl çalıştığını izleyin. Metrikleri görene ve nasıl göründüklerini, ürün sahibinin bunları bir sonraki brifingde CTO'ya nasıl sunacağını vs. etkileyene kadar geliştiricilerin izlemeye çaba ve zaman ayırmalarını sağlayamazsınız.
Kısacası
- Atınızı suya doğru yönlendirin. Geliştiricilere kendileri için ne kadar sorundan kaçınabileceklerini gösterin, uygulamaları için doğru KPI'ları ve ölçümleri belirlemelerine yardımcı olun, böylece CTO tarafından kendisine bağırılan ürün sahibinin daha az bağırması sağlanır. Onları yavaşça ve sakin bir şekilde ışığa getirin. Bu işe yaramazsa, rüşvet verin, tehdit edin ve bu ölçümleri uygulamalardan mümkün olduğunca hızlı bir şekilde almayı uygulaması için onlara veya ürün sahibine rüşvet verin, tehdit edin ve ikna edin ve ardından diyagramları çizin. Bir öncelik olarak görülmeyeceğinden ve ürün yol haritasında bekleyen birçok gelir getirici proje olacağından bu zor olacaktır. Bu nedenle, ürüne izleme uygulamak için harcanan zaman ve masrafı haklı çıkarmak için bir iş gerekçesine ihtiyacınız olacaktır.
- Sistem mühendislerinin iyi bir gece uykusu çekmesine yardımcı olun. Onlara, piyasaya sürülen herhangi bir ürün için "yayınlayalım" kontrol listesi kullanmanın iyi bir şey olduğunu gösterin. Üretimdeki tüm uygulamaların ölçümlerle kapsandığından emin olmak, geliştiricilerin neyin yanlış gittiğini ve nerede olduğunu görmesine olanak tanıyarak geceleri daha iyi uyumanıza yardımcı olacaktır. Ancak herhangi bir geliştiriciyi, ürün sahibini veya CTO'yu sinirlendirmenin ve hayal kırıklığına uğratmanın doğru yolu ısrar etmek ve direnmektir. Tekrar son dakikaya kadar beklerseniz bu davranış herhangi bir ürünün çıkış tarihini etkileyecektir; bu nedenle tekrar sola kaydırın ve bu sorunları mümkün olan en kısa sürede proje planınıza alın. Gerekirse ürün toplantılarına gidin. Takma bıyık ve keçe falan tak, asla başarısız olmaz. Endişelerinizi iletin, faydaları net bir şekilde gösterin ve müjdeyi duyurun.
- Hem geliştirmenin (geliştirme) hem de operasyonların (ops) kırmızı bölgeye giren ürün metriklerinin anlamını ve sonuçlarını anladığından emin olun. Ops'u ürün sağlığının tek koruyucusu olarak bırakmayın, geliştiricilerin de dahil olduğundan emin olun (#productsquads).
- Günlükler harika bir şeydir, ancak ölçümler de öyle. Bunları birleştirin ve kütüklerinizin büyük, yanan bir işe yaramazlık topunda çöp haline gelmesine izin vermeyin. Geliştiricilere neden başkalarının günlüklerini anlamayacağını açıklayın ve gösterin, onlara sabahın 3:15'inde işe yaramaz günlüklere bakmanın nasıl bir şey olduğunu gösterin.
fotoğrafı çeken üzerinde
Bu kadar. Gelecek hafta yeni materyal yayınlanacak. Kurs hakkında daha fazla bilgi edinmek isterseniz sizi davet ediyoruz. Pazartesi günü gerçekleşecek olan. Ve şimdi geleneksel olarak yorumlarınızı bekliyoruz.
Kaynak: habr.com