Здраво, Хабр! Ги поддржувам Highload IT системите веќе десет години. Нема да пишувам во оваа статија за проблемите со поставувањето на nginx да работи во режим на 1000+ RPS или други технички работи. Ќе ги споделам моите согледувања за проблемите во процесите кои се јавуваат при поддршката и функционирањето на ваквите системи.
Мониторинг
Техничката поддршка не чека додека не пристигне барање со содржина „Што зошто... страницата повторно не работи?“ Во рок од една минута по падот на страницата, поддршката веќе треба да го види проблемот и да започне да го решава. Но, локацијата е врвот на ледениот брег. Неговата достапност е една од првите што се следат.
Што да се прави со ситуацијата кога преостанатите стоки на онлајн продавница повеќе не пристигнуваат од системот ERP? Или CRM системот кој пресметува попусти за клиенти престана да реагира? Се чини дека страницата работи. Условниот Zabbix го добива својот одговор од 200. Дежурната смена не добила никакви известувања од мониторингот и со задоволство ја гледа првата епизода од новата сезона на Game of Thrones.
Следењето често е ограничено само на мерење на состојбата на меморијата, RAM меморијата и оптоварувањето на процесорот на серверот. Но, за бизнисот е многу поважно да се добие достапноста на производот на веб-страницата. Условниот неуспех на една виртуелна машина во кластерот ќе доведе до фактот дека сообраќајот ќе престане да оди до него и ќе се зголеми оптоварувањето на другите сервери. Компанијата нема да изгуби пари.
Затоа, покрај следењето на техничките параметри на оперативните системи на серверите, треба да ги конфигурирате деловните метрики. Метрики кои директно влијаат на парите. Различни интеракции со надворешни системи (CRM, ERP и други). Бројот на нарачки за одреден временски период. Успешни или неуспешни овластувања на клиентите и други показатели.
Интеракција со надворешни системи
Секоја веб-страница или мобилна апликација со годишен обрт од повеќе од милијарда рубли комуницира со надворешни системи. Почнувајќи од горенаведените CRM и ERP и завршувајќи со пренос на податоци за продажба на надворешен систем Big Data за анализа на набавките и понуда на клиентот производ што тој дефинитивно ќе го купи (всушност, не). Секој таков систем има своја поддршка. И често комуникацијата со овие системи предизвикува болка. Особено кога проблемот е глобален и треба да го анализирате во различни системи.
Некои системи обезбедуваат телефонски број или телеграма за нивните администратори. Некаде треба да напишете писма до менаџерите или да отидете до тракерите за грешки на овие надворешни системи. Дури и во контекст на една голема компанија, различни системи често работат во различни сметководствени системи за апликации. Понекогаш станува невозможно да се следи статусот на апликацијата. Добивате барање во една условна Jira. Потоа во коментарот на оваа прва Џира ставивте линк до прашањето во друга Џира. Во втората Жира во апликацијата некој веќе пишува коментар дека треба да го повикате условниот администратор Андреј за да го решите проблемот. И така натаму.
Најдоброто решение за овој проблем би било да се создаде единствен простор за комуникација, на пример во Slack. Ги поканува сите учесници во процесот на работење со надворешни системи да се приклучат. И, исто така, еден тракер за да не се дуплираат апликации. Апликациите треба да се следат на едно место, од следење известувања до излез на решенија за грешки во иднина. Ќе речете дека тоа е нереално и историски се случувало ние да работиме во еден тракер, а тие во друг. Се појавија различни системи, тие имаа свои автономни ИТ тимови. Се согласувам, и затоа проблемот треба да се реши одозгора на ниво на CIO или сопственик на производ.
Секој систем со кој комуницирате треба да обезбеди поддршка како услуга со јасна SLA за решавање на проблемите по приоритет. И не кога условниот админ Андреј има минута за вас.
Човек од тесно грло
Дали секој од некој проект (или производ) има личност чие заминување на одмор предизвикува грчеви кај нивните претпоставени? Ова може да биде инженер за devops, аналитичар или развивач. На крајот на краиштата, само инженер за devops знае кои сервери имаат инсталирани контејнери, како да се рестартира контејнерот во случај на проблем, и воопшто, секој сложен проблем не може да се реши без него. Аналитичарот е единствениот кој знае како функционира вашиот комплексен механизам. Кои текови на податоци каде одат. Под кои параметри на барања до кои услуги, на кои ќе добиеме одговори.
Кој брзо ќе разбере зошто има грешки во дневниците и веднаш ќе поправи критична грешка во производот? Се разбира, истиот програмер. Има и други, но поради некоја причина само тој разбира како функционираат различните модули на системот.
Коренот на овој проблем е недостатокот на документација. На крајот на краиштата, ако се опишани сите услуги на вашиот систем, тогаш би било можно да се справите со проблемот без аналитичар. Ако Девопс одзеде неколку дена од неговиот зафатен распоред и ги опиша сите сервери, услуги и упатства за решавање на типични проблеми, тогаш проблемот во негово отсуство може да се реши без него. Не треба брзо да го завршите пивото на плажа додека сте на одмор и да барате Wi-Fi за да го решите проблемот.
Компетентност и одговорност на помошниот персонал
На големи проекти, компаниите не штедат на платите на програмерите. Бараат скапи средни или постари лица од слични проекти. Со поддршка ситуацијата е малку поинаква. Тие се обидуваат да ги намалат овие трошоци на секој можен начин. Компаниите ангажираат евтини довчерашни работници на Еникеј и смело одат во битка. Оваа стратегија е можна ако зборуваме за веб-страница за визит-картичка на фабрика во Зеленоград.
Ако зборуваме за голема онлајн продавница, тогаш секој час застој чини повеќе од месечната плата на администратор на Enikey. Да земеме 1 милијарда рубли годишен обрт како почетна точка. Ова е минималниот промет на која било онлајн продавница од рејтингот . Поделете ја оваа сума со бројот на часови годишно и добијте повеќе од 100 рубли нето загуби. И ако не ги броите ноќните часови, можете безбедно да ја удвоите сумата.
Но, парите не се главната работа, нели? (не, се разбира главната работа) Има и загуби на угледот. Падот на добро позната онлајн продавница може да предизвика и бран критики на социјалните мрежи и публикации во тематски медиуми. А разговорите на пријателите во кујната во стилот „Не купувај ништо таму, нивната веб-страница е секогаш во прекин“ воопшто не може да се измерат.
Сега на одговорност. Во мојата пракса имаше случај дежурниот администратор да не одговори навреме на известување од мониторинг системот за недостапност на страницата. Во пријатна летна петочна вечер, тивко лежеше веб-страницата на добро позната онлајн продавница во Москва. Во саботата наутро, менаџерот на производи на оваа страница не разбра зошто страницата не се отвори, а во разговорите за поддршка и итни известувања во Slack владееше тишина. Таквата грешка нè чинеше шестцифрена сума, а овој дежурен работа.
Одговорноста е тешка вештина за развивање. Или човек го има или не. Затоа, за време на интервјуата, се обидувам да го идентификувам неговото присуство со различни прашања кои индиректно покажуваат дали човекот е навикнат да презема одговорност. Ако некој одговори дека избрал факултет затоа што тоа го кажале неговите родители или ја смени работата затоа што неговата сопруга рече дека не заработува доволно, тогаш подобро е да не се мешате со такви луѓе.
Интеракција со тимот за развој
Кога корисниците наидуваат на едноставни проблеми со некој производ за време на работата, поддршката сама ги решава. Се обидува да го репродуцира проблемот, ги анализира дневниците итн. Но, што да направите кога ќе се појави бубачка во производот? Во овој случај, поддршката им ја доделува задачата на програмерите и тука започнува забавата.
Програмерите постојано се преоптоварени. Тие создаваат нови функции. Поправање грешки со продажбата не е најинтересната активност. Се ближат роковите за завршување на следниот спринт. И тогаш доаѓаат непријатни луѓе од поддршка и велат: „Оставете сè веднаш, имаме проблеми“. Приоритетот на таквите задачи е минимален. Особено кога проблемот не е најкритичниот и кога главната функционалност на страницата работи, и кога менаџерот за ослободување не трча наоколу со испакнати очи и не пишува: „Итно додадете ја оваа задача на следното издание или жешка поправка“.
Проблемите со нормален или низок приоритет се преместуваат од издание во издание. На прашањето „Кога ќе се заврши задачата?“ ќе добиете одговори во стилот: „Извинете, има многу задачи во моментов, прашајте ги раководителите на вашиот тим или ослободи менаџерот“.
Проблемите со продуктивноста имаат поголем приоритет отколку создавањето нови функции. Лошите критики нема долго да доаѓаат ако корисниците постојано наидуваат на грешки. Нарушената репутација е тешко да се врати.
Прашањата за интеракцијата помеѓу развојот и поддршката ги решава DevOps. Оваа кратенка често се користи во форма на специфично лице кое помага да се создадат тест околини за развој, да се градат цевководи CICD и брзо да се внесе тестираниот код во производство. DevOps е пристап за развој на софтвер кога сите учесници во процесот тесно комуницираат едни со други и помагаат за брзо креирање и ажурирање софтверски производи и услуги. Мислам на аналитичари, програмери, тестери и поддршка.
Во овој пристап, поддршката и развојот не се различни одделенија со свои цели и задачи. Развојот е вклучен во работењето и обратно. Познатата фраза на дистрибуирани тимови: „Проблемот не е на моја страна“ повеќе не се појавува толку често во разговорите, а крајните корисници стануваат малку посреќни.
Извор: www.habr.com