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

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

мониторинг

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

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

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

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

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

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

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

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

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

Bottleneck Man

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

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

Компетентност и отговорност на помощния персонал

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

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

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

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

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

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

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

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

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

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

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

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

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