Пет проблема в процесите на експлоатация и поддръжка на Highload ИТ системи

Здравей, Хабр! Десет години поддържам Highload ИТ системи. Няма да пиша в тази статия за проблемите с настройката на nginx, за да работи в режим 1000+ RPS или други технически въпроси. Ще споделя наблюдения за проблемите в процесите, които възникват при поддръжката и експлоатацията на такива системи.

Мониторинг

Техническата поддръжка не чака да дойде заявка с текст „Защо... сайтът отново не работи?“. Поддръжката вече трябва да види проблема минута след падането на сайта и да започне да го решава. Но сайтът е върхът на айсберга.Неговата достъпност се следи сред първите.

Какво да правим, когато наличностите на стоки в интернет магазина спрат да идват от ERP системата? Или CRM системата, която изчислява отстъпки за клиентите, спре да отговаря? Сайтът обаче изглежда работи. Условният Zabbix получава своя 200 отговор. Дежурната смяна не е получила никакви известия от мониторинга и радостно довършва първия епизод от новия сезон на „Игра на тронове“.

Често мониторингът се ограничава само до измерване на състоянието на паметта, оперативната памет и натоварването на процесорите. сървъри. Но за бизнеса е много по-важно да получи достъпност на стоките на сайта. Условно падане на една виртуална машина в кластера ще доведе до спиране на трафика към нея и до увеличаване на натоварването на другите сървъри. Парите компанията няма да загуби.

Затова, освен мониторинг на техническите параметри на операционните системи на сървърите, е нужно да се настройват бизнес метрики. Метрики, които пряко влияят на парите. Различни взаимодействия с външни системи (CRM, ERP и др.). Броят на поръчките за определен период от време. Успешните или неуспешни авторизации на клиентите и други метрики.

Взаимодействие с външни системи

Всеки сайт или мобилно приложение с годишен оборот над един милиард рубли взаимодействат с външни системи. Започвайки от споменатите CRM и ERP и завършвайки с предаване на данни за продажби на външна Big Data система за анализ на покупките и предлагане на на клиента стока, която той със сигурност ще купи (в действителност не е така). Всяка такава система има своя собствена поддръжка. И често общуването с тези системи предизвиква болка. Особено когато проблемът е глобален и трябва да бъде анализиран в различни системи.

Някои системи предоставят телефон или telegram на своите администратори. В други случаи трябва да пишете имейли на мениджърите или да посещавате баг тракери на тези външни системи. Дори в пределите на една голяма компания различните системи често работят в различни системи за управление на заявки. Проследяването на статуса на заявката понякога става невъзможно. Получавате заявка в една условна Jira. След това в коментара на тази първа Jira поставяте връзка към задачата в друга Jira. Във втората Jira някой вече пише коментар, че трябва да се обадите на условния администратор Андрей, за да решите въпроса. И така нататък.

Оптималното решение на този проблем би било създаването на единно пространство за комуникация, например в Slack. Поканете всички участници в процеса на експлоатация на външните системи. А също така единен трекер, за да не дублирате заявки. Заявките трябва да се проследяват на едно място, започвайки от уведомлението за мониторинг до изхода на решенията на бъговете в продукция. Ще кажете, че това е нереално и така исторически сте работили, че ние работим в един трекер, а те в друг. Появиха се различни системи, имали са свои автономни ИТ екипи. Съгласен съм и поради това проблемът трябва да се решава отгоре, на ниво CIO или product owner.

Всяка система, с която взаимодействате, трябва да предлага поддръжка като услуга с ясна SLA за решаване на проблеми по приоритети. А не когато на условния администратор Андрей му се появи свободен момент.

Човек - бутилково гърло

При всеки проект (или продукт) има такъв човек, чийто отпуск предизвиква у началството спазми? Това може да бъде devops инженер, анализатор или разработчик. Нали само devops инженерът знае на какви сървъри са инсталирани какви контейнери, как да рестартира контейнер при проблем и изобщо всякакви сложни проблеми без него не се решават. Анализаторът - единственият знае как работи вашият сложен механизъм. Какви потоци данни къде отиват. При какви параметри на запитванията до кои услуги, какви отговори ще получим.
Кой бързо ще разбере защо в логовете има грешки и бързо ще поправи критичния бъг в продукция? Разбира се, този разработчик. Има и други, но по някаква причина само той разбира как функционират различните модули на системата.

Коренът на този проблем е липсата на документацияЗащото ако всички услуги на вашата система бяха описани, би могло да се справите с проблема и без аналитик. Ако devops отдели няколко дни от натоварения си график и опише всички сървъри, услуги и инструкции за решаване на типични проблеми, проблемът в негово отсъствие можеше да бъде решен и без него. Няма нужда бързо да изпивате бирата си на плажа по време на отпуска и да търсите wi-fi, за да разрешите проблема.

Компетентност и отговорност на служителите по поддръжката

При големи проекти компаниите не пестят от заплатите на разработчиците. Наемат скъпи мидлове или сеньори от сходни проекти. Ситуацията с поддръжката е малко по-различна. Тези разходи се опитват всячески да се съкратят. Компаниите наемат недорги вчерашни техници и смело отиват на битка. Такава стратегия е възможна, когато става въпрос за сайт-визитка на някакъв завод в Зеленоград.

Ако става въпрос за голям интернет магазин, всеки час престой струва повече от месечната заплата на администратор-техник. Нека вземем за отправна точка 1 милиард рубли годишен оборот. Това е минималният оборот на всеки интернет магазин от рейтинга ТОП-100 за 2018 година. Разделяме тази сума на броя часове в годината и получаваме повече от 100 000 рубли чисти загуби. А ако не считаме нощните часове, можем смело да удвоим сумата.

Но парите всъщност не са най-важното, нали? (не, разбира се, че са важни) Има и репутационни загуби. Час на падение на известен интернет магазин може да предизвика както вълна от отзиви в социалните мрежи, така и публикации в тематични медии. А разговорите на приятели в кухнята в стил „Не купувай там нищо, техният сайт постоянно не работи“ изобщо не подлежат на измерване.

Сега за отговорността. В моята практика имаше случай, когато дежурният администратор не реагира навреме на уведомление от системата за мониторинг за недостъпност на сайта. В приятен летен петък вечер сайтът на един известен интернет магазин в Москва тихо беше паднал. В събота сутринта продуктовият мениджър на този сайт не разбираше защо сайтът не се отваря, а в чатовете за поддръжка и спешни уведомления в Slack цареше тишина. Тази грешка ни струваше шестцифрена сума, а на този дежурен - работа.

Отговорността е умение, което е трудно да се развие. Има ли у човека или не. Затова на интервюта се стремя да открия нейното наличие чрез различни въпроси, които непряко показват свикнал ли е човекът да поема отговорност. Ако човек отговори, че е избрал ВУЗ, защото така са казали родителите или сменя работа, защото жена му е казала, че печели малко, то с такива хора е по-добре да не се свързвате.

Взаимодействие с екипа по разработка

Когато в продукция, в процеса на експлоатация, на потребителите им възникват несложни проблеми, то поддръжката ги решава сама. Опитва се да възпроизведе проблема, анализира логовете и т.н. Но какво да се прави, когато на продакшън излезе бъг? В този случай поддръжката създава задача за разработчиците и тук започва най-интересното.

Разработчиците постоянно са натоварени. Те се занимават с разработване на нови функции. Поправянето на бъгове с продукционния софтуер е, да кажем, не най-интересното занимание. Изтичат сроковете за завършване на поредния спринт. А тук идват неприятни хора отподдръжката и казват: „Спешно остави всичко, имаме проблеми“. Приоритетът на такива задачи е минимален. Особено когато проблемът не е най-критичният и основната функционалност на сайта работи, а и когато мениджърът на версията не тича с широко отворени очи и не пише: „Спешно включи тази задача в най-близкия релиз или гореща поправка”.

Задачи с нормален или нисък приоритет преминават от релиз в релиз. На въпроса „Кога задачата ще бъде изпълнена?“ ще получаваш отговори в стил: „Извини, сега имаме много задачи, питай тим лидовете или мениджъра на версията“.

Проблемите в продукция имат по-висок приоритет от създаването на нови функции. Лошите отзиви няма да се забавят, ако потребителите постоянно попадат на бъгове. Повредената репутация трудно се възстановява.

Въпросите за взаимодействие между разработката и поддръжката се решават от DevOps. Тази абревиатура често се употребява в ролята на конкретен човек, който помага за създаването на тестови среди за разработка, изгражда CICD пайплайни и бързо внедрява тестван код в продукция. DevOps е подход към разработката на софтуер, когато всички участници в процеса тясно взаимодействат помежду си и помагат за по-бързото създаване и актуализиране на софтуерни продукти и услуги. Имам предвид анализатори, разработчици, тестери и поддръжка.

Поддръжката и разработката в такъв подход не са различни отдели с различни цели и задачи. Разработката е ангажирана в експлоатацията и обратно. Известната фраза за разпределени екипи: "Проблемът не е от моята страна" вече не се среща толкова често в чатовете, а крайните потребители стават малко по-щастливи.

Източник: habr.com