Merhaba Habr! On yıldır Highload IT sistemlerini destekliyorum. Bu yazıda nginx'i 1000+ RPS modunda çalışacak şekilde ayarlama sorunları veya diğer teknik konular hakkında yazmayacağım. Bu tür sistemlerin desteklenmesinde ve işletilmesinde ortaya çıkan süreçlerde yaşanan sorunlara ilişkin gözlemlerimi paylaşacağım.
İzleme
Teknik destek, "Ne Neden... site tekrar çalışmıyor?" içerikli bir talep gelene kadar beklemez. Sitenin çökmesinden sonraki bir dakika içinde destek ekibinin sorunu görmesi ve çözmeye başlaması gerekir. Ancak site buzdağının görünen kısmı. Kullanılabilirliği ilk izlenenlerden biridir.
Bir çevrimiçi mağazanın kalan ürünlerinin artık ERP sisteminden gelmemesi durumunda ne yapmalı? Yoksa müşteriler için indirimleri hesaplayan CRM sistemi yanıt vermeyi mi bıraktı? Site çalışıyor gibi görünüyor. Koşullu Zabbix 200 yanıtını alır. İzlemeden herhangi bir bildirim gelmeyen nöbetçi vardiya, Game of Thrones'un yeni sezonunun ilk bölümünü mutlu bir şekilde izliyor.
İzleme genellikle yalnızca belleğin, RAM'in ve sunucu işlemci yükünün durumunun ölçülmesiyle sınırlıdır. Ancak iş için web sitesinde ürünün bulunabilirliğini sağlamak çok daha önemlidir. Kümedeki bir sanal makinenin koşullu arızası, trafiğin ona gitmesinin durmasına ve diğer sunuculardaki yükün artmasına neden olacaktır. Şirket para kaybetmeyecek.
Bu nedenle sunuculardaki işletim sistemlerinin teknik parametrelerini izlemenin yanı sıra iş metriklerini de yapılandırmanız gerekir. Parayı doğrudan etkileyen metrikler. Dış sistemlerle (CRM, ERP ve diğerleri) çeşitli etkileşimler. Belirli bir süre için sipariş sayısı. Başarılı veya başarısız müşteri yetkilendirmeleri ve diğer ölçümler.
Harici sistemlerle etkileşim
Yıllık cirosu bir milyar rubleyi aşan herhangi bir web sitesi veya mobil uygulama, harici sistemlerle etkileşime girer. Yukarıda belirtilen CRM ve ERP'den başlayıp, satın almaları analiz etmek ve müşteriye kesinlikle satın alacağı (aslında almayacağı) bir ürün sunmak için satış verilerinin harici bir Büyük Veri sistemine aktarılmasıyla sona erer. Bu tür sistemlerin her birinin kendi desteği vardır. Ve sıklıkla bu sistemlerle iletişim ağrıya neden olur. Özellikle sorun küresel olduğunda ve onu farklı sistemlerde analiz etmeniz gerektiğinde.
Bazı sistemler yöneticilerine bir telefon numarası veya telgraf sağlar. Bir yerlerde yöneticilere mektup yazmanız veya bu harici sistemlerin hata takipçilerine gitmeniz gerekiyor. Büyük bir şirket bağlamında bile, farklı uygulama muhasebesi sistemlerinde sıklıkla farklı sistemler çalışır. Bazen bir uygulamanın durumunu takip etmek imkansız hale gelir. Bir koşullu Jira'da bir istek alırsınız. Daha sonra bu ilk Jira'nın yorumuna başka bir Jira'daki konunun bağlantısını koymuşsunuz. Uygulamadaki ikinci Jira'da birisi zaten bir yorum yazıyor Sorunu çözmek için koşullu yönetici Andrey'i aramanız gerekiyor. Ve böyle devam eder.
Bu sorunun en iyi çözümü örneğin Slack'te iletişim için tek bir alan oluşturmak olacaktır. Dış sistemlerin çalıştırılması sürecindeki tüm katılımcıları katılmaya davet ediyoruz. Ayrıca uygulamaları çoğaltmamak için tek bir izleyici. Uygulamaların, bildirimlerin izlenmesinden, gelecekte hata çözümlerinin çıktısına kadar tek bir yerden takip edilmesi gerekiyor. Bunun gerçekçi olmadığını ve tarihsel olarak biz bir izleyicide çalışırken onların başka bir izleyicide çalıştığını söyleyeceksiniz. Farklı sistemler ortaya çıktı, kendi özerk BT ekipleri vardı. Katılıyorum ve bu nedenle sorunun CIO veya ürün sahibi düzeyinde yukarıdan çözülmesi gerekiyor.
Etkileşim kurduğunuz her sistem, sorunları öncelik sırasına göre çözmek için net bir SLA'ya sahip bir hizmet olarak destek sağlamalıdır. Ve şartlı yönetici Andrey'in sana ayıracak bir dakikası varken değil.
Darboğaz Adam
Bir projede (veya üründe) herkesin tatile çıkması üstleri arasında sarsıntıya neden olan bir kişi var mı? Bu bir devops mühendisi, analisti veya geliştiricisi olabilir. Sonuçta, hangi sunucularda hangi konteynerlerin yüklü olduğunu, bir sorun durumunda konteynerin nasıl yeniden başlatılacağını yalnızca bir devops mühendisi bilir ve genel olarak herhangi bir karmaşık sorun onsuz çözülemez. Analist, karmaşık mekanizmanızın nasıl çalıştığını bilen tek kişidir. Hangi veri akışları nereye gidiyor? Hangi hizmetlere, hangi taleplere hangi parametrelerle yanıt alacağız.
Günlüklerde neden hatalar olduğunu kim hızlı bir şekilde anlayacak ve üründeki kritik bir hatayı derhal düzeltecek? Tabii ki aynı geliştirici. Başkaları da var, ancak bazı nedenlerden dolayı sistemin farklı modüllerinin nasıl çalıştığını yalnızca o anlıyor.
Bu sorunun temelinde belge eksikliği var. Sonuçta, sisteminizin tüm hizmetleri tanımlanmış olsaydı, sorunu bir analist olmadan çözmek mümkün olurdu. Devops yoğun programından birkaç gün ayırıp tüm sunucuları, hizmetleri ve tipik sorunları çözmek için talimatları açıklasaydı, o zaman onun yokluğunda sorun onsuz çözülebilirdi. Tatildeyken sahilde biranızı hızlıca bitirip sorunu çözmek için wi-fi aramanıza gerek yok.
Destek personelinin yetkinliği ve sorumluluğu
Büyük projelerde şirketler geliştirici maaşlarından mahrum kalmıyor. Benzer projelerden pahalı orta veya yaşlılar arıyorlar. Destek konusunda ise durum biraz farklıdır. Bu maliyetleri mümkün olan her şekilde azaltmaya çalışıyorlar. Şirketler dünün Enikey işçilerini ucuza işe alıyor ve cesurca savaşa giriyor. Zelenograd'daki bir fabrikanın kartvizit web sitesinden bahsediyorsak bu strateji mümkündür.
Büyük bir çevrimiçi mağazadan bahsediyorsak, her saatlik kesinti, bir Enikey yöneticisinin aylık maaşından daha fazlaya mal olur. Başlangıç noktası olarak 1 milyar ruble yıllık ciroyu alalım. Bu, herhangi bir çevrimiçi mağazanın derecelendirmeden elde ettiği minimum cirodur . Bu tutarı yıllık saat sayısına bölün ve 100 ruble'den fazla net kayıp elde edin. Ve eğer gece saatlerini saymazsanız, bu miktarı güvenle iki katına çıkarabilirsiniz.
Ama asıl önemli olan para değil, değil mi? (hayır tabii ki asıl mesele) İtibar kayıpları da var. Tanınmış bir çevrimiçi mağazanın çöküşü, hem sosyal ağlarda bir inceleme dalgasına hem de tematik medyadaki yayınlara neden olabilir. Ve mutfakta arkadaşların “Sakın oradan bir şey almayın, siteleri hep kapalı” tarzında konuşmaları da hiç ölçülemez.
Şimdi sorumluluk. Uygulamamda, görevdeki yöneticinin, izleme sisteminden sitenin kullanılamadığına ilişkin bir bildirime zamanında yanıt vermediği bir durum vardı. Keyifli bir yaz Cuma akşamı, Moskova'daki tanınmış bir çevrimiçi mağazanın web sitesi sessizce duruyordu. Cumartesi sabahı bu sitenin ürün yöneticisi sitenin neden açılmadığını anlayamadı ve Slack'te destek ve acil bildirim sohbetlerinde sessizlik oluştu. Böyle bir hata bize altı haneli bir maliyete ve bu görevli memurun işine mal oldu.
Sorumluluk geliştirilmesi zor bir beceridir. Bir kişide ya vardır ya da yoktur. Bu nedenle görüşmeler sırasında kişinin sorumluluk almaya alışkın olup olmadığını dolaylı olarak gösteren çeşitli sorularla onun varlığını tespit etmeye çalışıyorum. Eğer kişi anne ve babasının söylediği için üniversiteyi seçtiğini ya da karısı yeterince kazanamadığı için iş değiştirdiğini söylüyorsa, bu tür insanlarla ilişki kurmamak daha iyidir.
Geliştirme ekibiyle etkileşim
Kullanıcılar, çalışma sırasında bir ürünle ilgili basit sorunlarla karşılaştıklarında destek bunları kendi başına çözer. Sorunu yeniden oluşturmaya çalışır, günlükleri analiz eder vb. Peki üründe bir hata ortaya çıktığında ne yapmalı? Bu durumda destek, görevi geliştiricilere atar ve eğlence burada başlar.
Geliştiriciler sürekli olarak aşırı yükleniyor. Yeni özellikler yaratıyorlar. Satışlardaki hataları düzeltmek en ilginç aktivite değildir. Bir sonraki sprint'i tamamlamak için son tarihler yaklaşıyor. Sonra destekten hoş olmayan insanlar gelip şöyle diyorlar: “Hemen her şeyi bırakın, sorunlarımız var.” Bu tür görevlerin önceliği minimumdur. Özellikle sorun en kritik olmadığında ve sitenin ana işlevselliği çalıştığında ve sürüm yöneticisi şişkin gözlerle etrafta dolaşıp şunu yazmadığında: "Bu görevi acilen bir sonraki sürüme veya düzeltmeye ekleyin."
Normal veya düşük öncelikli sorunlar bir yayından diğerine taşınır. "Görev ne zaman tamamlanacak?" şu tarzda yanıtlar alacaksınız: "Kusura bakmayın, şu anda çok fazla görev var, ekip liderlerinize veya sürüm yöneticinize sorun."
Verimlilik sorunları, yeni özellikler oluşturmaktan daha önceliklidir. Kullanıcılar sürekli olarak hatalarla karşılaşırsa, kötü incelemelerin gelmesi uzun sürmeyecektir. Hasar görmüş bir itibarın onarılması zordur.
Geliştirme ve destek arasındaki etkileşim sorunları DevOps tarafından çözülür. Bu kısaltma genellikle geliştirme için test ortamları oluşturmaya yardımcı olan, CICD ardışık düzenleri oluşturan ve test edilen kodu hızlı bir şekilde üretime getiren belirli bir kişi biçiminde kullanılır. DevOps, süreçteki tüm katılımcıların birbirleriyle yakın etkileşime girdiği ve yazılım ürün ve hizmetlerinin hızlı bir şekilde oluşturulup güncellenmesine yardımcı olduğu bir yazılım geliştirme yaklaşımıdır. Analistleri, geliştiricileri, test uzmanlarını ve desteği kastediyorum.
Bu yaklaşımda destek ve geliştirme, kendi amaç ve hedefleri olan farklı departmanlar değildir. Geliştirme operasyona dahil edilir ve bunun tersi de geçerlidir. Dağıtılmış ekiplerin meşhur sözü: “Sorun bende değil” artık sohbetlerde pek sık görülmüyor ve son kullanıcılar biraz daha mutlu oluyor.
Kaynak: habr.com