Salam, Habr! Mən on ildir ki, Highload İT sistemlərini dəstəkləyirəm. Bu məqalədə nginx-in 1000+ RPS rejimində işləmək üçün qurulması problemləri və ya digər texniki şeylər haqqında yazmayacağam. Bu cür sistemlərin dəstəklənməsi və işlədilməsi zamanı yaranan proseslərdə yaranan problemlər haqqında müşahidələrimi bölüşəcəyəm.
Monitorinq
Texniki dəstək “Nə üçün... sayt yenidən işləmir?” məzmunlu sorğu gələnə qədər gözləmir. Sayt çökdükdən sonra bir dəqiqə ərzində dəstək problemi görüb həll etməyə başlamalıdır. Ancaq sayt aysberqin görünən hissəsidir. Onun mövcudluğu ilk izlənilənlərdən biridir.
Onlayn mağazanın qalan malları artıq ERP sistemindən gəlmədikdə vəziyyətlə nə etməli? Yoxsa müştərilər üçün endirimləri hesablayan CRM sistemi cavab verməyi dayandırıb? Deyəsən sayt işləyir. Şərti Zabbix 200 cavabını alır. Növbətçi növbə monitorinqdən heç bir bildiriş almayıb və “Game of Thrones” serialının yeni mövsümünün ilk bölümünü sevinclə izləyir.
Monitorinq çox vaxt yalnız yaddaşın, operativ yaddaşın və server prosessorunun yükünün vəziyyətini ölçməklə məhdudlaşır. Lakin biznes üçün vebsaytda məhsulun mövcudluğunu əldə etmək daha vacibdir. Klasterdəki bir virtual maşının şərti nasazlığı trafikin ona getməsini dayandırmasına və digər serverlərdə yükün artmasına səbəb olacaq. Şirkət pul itirməyəcək.
Buna görə də, serverlərdə əməliyyat sistemlərinin texniki parametrlərinə nəzarət etməklə yanaşı, biznes ölçülərini konfiqurasiya etməlisiniz. Pullara birbaşa təsir edən ölçülər. Xarici sistemlərlə müxtəlif qarşılıqlı əlaqələr (CRM, ERP və s.). Müəyyən bir müddət üçün sifarişlərin sayı. Uğurlu və ya uğursuz müştəri icazələri və digər ölçülər.
Xarici sistemlərlə qarşılıqlı əlaqə
İllik dövriyyəsi milyard rubldan çox olan istənilən veb-sayt və ya mobil proqram xarici sistemlərlə qarşılıqlı əlaqədə olur. Yuxarıda qeyd olunan CRM və ERP-dən başlayaraq alışları təhlil etmək və müştəriyə mütləq alacağı (əslində yox) məhsulu təklif etmək üçün satış məlumatlarının xarici Big Data sisteminə ötürülməsi ilə başa çatır. Hər bir belə sistemin öz dəstəyi var. Və tez-tez bu sistemlərlə ünsiyyət ağrıya səbəb olur. Xüsusilə problem qlobal olduqda və onu müxtəlif sistemlərdə təhlil etmək lazımdır.
Bəzi sistemlər administratorları üçün telefon nömrəsi və ya teleqram təqdim edir. Haradasa menecerlərə məktublar yazmaq və ya bu xarici sistemlərin səhv izləyicilərinə getmək lazımdır. Hətta bir böyük şirkətin kontekstində müxtəlif sistemlər tez-tez müxtəlif tətbiq mühasibat sistemlərində işləyir. Bəzən tətbiqin statusunu izləmək mümkün olmur. Bir şərti Jirada sorğu alırsınız. Sonra bu birinci Jiranın şərhində başqa bir Jirada məsələyə keçid qoyursan. Tətbiqdə ikinci Jirada artıq kimsə şərh yazır ki problemi həll etmək üçün şərti admin Andreyə zəng etməlisiniz. Və s.
Bu problemin ən yaxşı həlli, məsələn, Slack-də ünsiyyət üçün vahid məkan yaratmaq olardı. Xarici sistemlərin istismarı prosesində iştirak edən bütün iştirakçıları qoşulmağa dəvət edirik. Həm də tətbiqləri təkrarlamamaq üçün tək izləyici. Tətbiqlər monitorinq bildirişlərindən tutmuş gələcəkdə səhv həllərinin çıxışına qədər bir yerdə izlənilməlidir. Deyəcəksiniz ki, bu qeyri-realdır və tarixən belə olub ki, biz bir izləyicidə işləyirik, onlar isə başqasında işləyirlər. Fərqli sistemlər meydana çıxdı, onların öz muxtar İT komandaları var idi. Razıyam və buna görə də problemi yuxarıdan CIO və ya məhsul sahibi səviyyəsində həll etmək lazımdır.
Qarşılıqlı əlaqə qurduğunuz hər bir sistem problemləri prioritetlə həll etmək üçün aydın SLA ilə xidmət kimi dəstək verməlidir. Və şərti admin Andreyin sizin üçün bir dəqiqəsi olanda deyil.
Darboğaz Adam
Bir layihədə (və ya məhsulda) hər kəsin tətilə getməsi rəhbərləri arasında qıcolmalara səbəb olan bir adam varmı? Bu devops mühəndisi, analitiki və ya tərtibçisi ola bilər. Axı, yalnız devops mühəndisi bilir ki, hansı serverlərdə hansı konteynerlər quraşdırılıb, problem yarandıqda konteyneri necə yenidən işə salmaq olar və ümumiyyətlə, hər hansı mürəkkəb problem onsuz həll oluna bilməz. Analitik sizin mürəkkəb mexanizminizin necə işlədiyini bilən yeganə şəxsdir. Hansı məlumat axınları hara gedir. Hansı xidmətlərə edilən sorğuların hansı parametrləri altında, hansılara cavab alacağıq.
Kim qeydlərdə niyə səhvlərin olduğunu tez başa düşəcək və məhsuldakı kritik səhvi dərhal düzəldəcək? Əlbəttə ki, eyni tərtibatçı. Başqaları da var, amma nədənsə sistemin müxtəlif modullarının necə işlədiyini yalnız o başa düşür.
Bu problemin kökündə sənədləşmənin olmaması dayanır. Axı, sisteminizin bütün xidmətləri təsvir edilsəydi, o zaman analitik olmadan problemlə məşğul olmaq mümkün olardı. Əgər devops məşğul iş qrafikindən bir neçə gün çıxarıb bütün serverləri, xidmətləri və tipik problemlərin həlli üçün təlimatları təsvir etsəydi, onun yoxluğunda problem onsuz da həll edilə bilərdi. Tətildə olarkən çimərlikdə pivənizi tez bitirməyə və problemi həll etmək üçün wi-fi axtarmağa ehtiyac yoxdur.
Köməkçi heyətin səriştəsi və məsuliyyəti
Böyük layihələrdə şirkətlər developer maaşlarına qənaət etmirlər. Onlar oxşar layihələrdən bahalı orta və ya yaşlılar axtarırlar. Dəstəklə vəziyyət bir az fərqlidir. Bu xərcləri hər cür azaltmağa çalışırlar. Şirkətlər ucuz dünənki Enikey işçilərini işə götürür və cəsarətlə döyüşə girirlər. Zelenoqraddakı bir zavodun vizit kartı saytından danışırıqsa, bu strategiya mümkündür.
Əgər böyük bir onlayn mağazadan danışırıqsa, onda hər bir iş saatı Enikey administratorunun aylıq maaşından baha başa gəlir. Başlanğıc olaraq illik dövriyyənin 1 milyard rublunu götürək. Bu, reytinqdən istənilən onlayn mağazanın minimum dövriyyəsidir . Bu məbləği ildə saatların sayına bölün və 100 rubldan çox xalis itki əldə edin. Gecə saatlarını saymasanız, məbləği ikiqat artıra bilərsiniz.
Amma əsas şey pul deyil, elə deyilmi? (yox, əlbəttə ki, əsas) Reputasiya itkiləri də var. Tanınmış onlayn mağazanın süqutu həm sosial şəbəkələrdə rəy dalğasına, həm də tematik mediada nəşrlərə səbəb ola bilər. Mətbəxdəki dostların “Oradan heç nə almayın, onların internet saytı həmişə işləyir” üslubunda söhbətləri heç cür ölçülə bilməz.
İndi məsuliyyətə. Mənim təcrübəmdə belə bir hal olub ki, növbətçi inzibatçı saytın mövcud olmaması ilə bağlı monitorinq sistemindən gələn bildirişə vaxtında cavab vermir. Xoş bir yay cümə axşamı, Moskvada məşhur bir onlayn mağazanın veb saytı sakitcə uzandı. Şənbə günü səhər bu saytın məhsul meneceri saytın niyə açılmadığını başa düşmədi və Slack-də dəstək və təcili bildiriş çatlarında səssizlik hökm sürürdü. Belə bir səhv bizə altı rəqəm bahasına başa gəldi və bu növbətçi öz işi idi.
Məsuliyyət inkişaf etdirmək çətin bir bacarıqdır. İnsanda ya var, ya da yoxdur. Ona görə də müsahibələr zamanı insanın məsuliyyəti öz üzərinə götürməyə vərdiş edib-etmədiyini dolayısı ilə göstərən müxtəlif suallarla onun varlığını müəyyən etməyə çalışıram. Əgər kimsə cavab verirsə ki, valideynlərinin dediklərinə görə universiteti seçib və ya arvadı maaşının az olduğunu dediyi üçün işini dəyişib, o zaman belə insanlarla əlaqə saxlamamaq daha yaxşıdır.
İnkişaf komandası ilə qarşılıqlı əlaqə
İstifadəçilər əməliyyat zamanı məhsulla bağlı sadə problemlərlə qarşılaşdıqda, dəstək onları özbaşına həll edir. Problemi təkrar etməyə çalışır, jurnalları təhlil edir və s. Bəs məhsulda bir səhv görünəndə nə etməli? Bu halda, dəstək tapşırığı tərtibatçılara verir və əyləncə burada başlayır.
Tərtibatçılar daim həddən artıq yüklənir. Onlar yeni funksiyalar yaradırlar. Satışlarla səhvləri düzəltmək ən maraqlı fəaliyyət deyil. Növbəti sprinti tamamlamaq üçün son tarixlər yaxınlaşır. Sonra dəstəkdən xoşagəlməz insanlar gəlir və deyirlər: "Hər şeydən dərhal əl çəkin, problemimiz var." Bu cür vəzifələrin prioriteti minimaldır. Xüsusilə problem ən kritik olmayanda və saytın əsas funksionallığı işlədikdə və buraxılış meneceri qabarıq gözlərlə qaçmadıqda və yazın: "Təcili olaraq bu tapşırığı növbəti buraxılışa və ya düzəlişə əlavə edin."
Normal və ya aşağı prioritetli məsələlər buraxılışdan buraxılışa köçürülür. “Tapşırıq nə vaxt tamamlanacaq?” sualına aşağıdakı üslubda cavablar alacaqsınız: "Bağışlayın, hazırda çoxlu tapşırıqlar var, komandanızın rəhbərlərindən soruşun və ya menecerinizi buraxın."
Məhsuldarlıq problemləri yeni funksiyalar yaratmaqdan daha yüksək prioritet təşkil edir. İstifadəçilər daim səhvlərlə qarşılaşsalar, pis rəylər çox çəkməyəcək. Zədələnmiş reputasiyanı bərpa etmək çətindir.
İnkişaf və dəstək arasında qarşılıqlı əlaqə məsələləri DevOps tərəfindən həll edilir. Bu abbreviatura tez-tez inkişaf üçün test mühitləri yaratmağa kömək edən, CICD boru kəmərlərini quran və sınaqdan keçmiş kodu tez bir zamanda istehsala gətirən xüsusi bir şəxs şəklində istifadə olunur. DevOps, prosesin bütün iştirakçılarının bir-biri ilə sıx əlaqədə olduğu və proqram məhsulları və xidmətlərini tez bir zamanda yaratmağa və yeniləməyə kömək etdiyi zaman proqram təminatının hazırlanmasına yanaşmadır. Mən analitikləri, tərtibatçıları, testçiləri və dəstəyi nəzərdə tuturam.
Bu yanaşmada dəstək və inkişaf öz məqsəd və vəzifələri olan fərqli şöbələr deyil. İnkişaf əməliyyatda iştirak edir və əksinə. Paylanmış komandaların məşhur ifadəsi: "Problem mənim tərəfimdə deyil" artıq çatlarda tez-tez görünmür və son istifadəçilər bir az daha xoşbəxt olurlar.
Mənbə: www.habr.com