Прывітанне, Хабр! Дзесяць гадоў я падтрымліваю 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 000 рублёў чыстых страт. А калі не лічыць начны гадзіннік, то можна смела павялічваць суму ў два разы.
Але ж грошы не галоўнае, так? (не, вядома галоўнае) Ёсць яшчэ рэпутацыйнага страты. Гадзіна падзення вядомай інтэрнэт-крамы можа выклікаць як хвалю водгукаў у сацыяльных сетках, так і публікацыі ў тэматычных СМІ. А размовы сяброў на кухні ў стылі "Не купляй там нічога, у іх сайт пастаянна не працуе" наогул не паддаюцца вымярэнням.
Цяпер да адказнасці. У маёй практыцы быў выпадак, калі дзяжурны адміністратар не зрэагаваў своечасова на апавяшчэнне сістэмы маніторынгу аб недаступнасці сайта. У прыемны летні пятнічны вечар і сайт адной вядомай у Маскве інтэрнэт-крамы ціха ляжаў. У суботу раніцай продакт гэтага сайта не зразумеў чаму сайт не адчыняецца, а ў чатах падтрымкі і тэрміновых абвестак у Slack цішыня. Такая памылка каштавала нам шасцізначнай сумы, а гэтаму дзяжурнаму працы.
Адказнасць - навык які цяжка развіць. Ён ці ёсць у чалавека ці не. Таму на сумоўях я імкнуся выявіць яе наяўнасць рознымі пытаннямі, якія ўскосна паказваюць ці прывык чалавек браць адказнасць на сябе. Калі чалавек адказвае, што абраў ВНУ, таму што так сказалі бацькі ці мяняе працу з-за таго, што жонка сказала, што ён мала атрымлівае, то з такімі людзьмі лепш не звязвацца.
Узаемадзеянне з камандай распрацоўкі
Калі на прадуктыве падчас эксплуатацый у карыстачоў узнікаюць нескладаныя праблемы, то падтрымка вырашае іх саматугам. Спрабуе прайграць праблему, аналізуе логі і гэтак далей. Але што рабіць, калі на продзе ўсплыў баг? У гэтым выпадку падтрымка заводзіць задачу на распрацоўшчыкаў і вось тут пачынаецца самае цікавае.
Распрацоўнікі стала перагружаныя. Яны займаюцца стварэннем новых фіч. Фіксаваць багі з прода занятак скажам не самае цікавае. Гараць тэрміны для завяршэння чарговага спрынту. А тут прыходзяць непрыемныя людзі з падтрымкі і кажуць: "Тэрмінова кідай усё, у нас праблемы". Прыярытэт такіх задач мінімальны. Асабліва калі праблема не самая крытычная і асноўны функцыянал сайта працуе, і калі рэліз-мэнэджар не бегае з вылупленымі вачыма і не піша: "Тэрмінова ўнесці гэтую задачу ў бліжэйшы рэліз або хотфікс".
Задачы са звычайным ці нізкім прыярытэтам пераходзяць з рэлізу ў рэліз. На пытанне "Калі задача будзе выканана?" ты будзеш атрымліваць адказы ў стылі: "Прабач, цяпер шмат задач, спытай у тым лідаў або рэліз мэнэджара".
Праблемы на прадуктыве маюць большы прыярытэт, чым стварэнне новых фічоў. Дрэнныя водгукі не прымусяць сябе чакаць, калі карыстачы будуць увесь час натыкацца на багі. Сапсаваную рэпутацыю аднаўляць цяжка.
Пытанні ўзаемадзеяння распрацоўкі і падтрымкі вырашае DevOps. Гэтую абрэвіятуру часта ўжываюць у выглядзе канкрэтнага чалавека, які дапамагае ствараць тэставыя асяроддзі для распрацоўкі, выбудоўвае CICD пайплайны і хутка выводзіць пратэставаны код у прадакшн. DevOps - падыход да распрацоўкі ПЗ, калі ўсе ўдзельнікі працэсу шчыльна ўзаемадзейнічаюць адзін з адным і дапамагаюць хутчэй ствараць і абнаўляць праграмныя прадукты і паслугі. Я маю на ўвазе аналітыкаў, распрацоўшчыкаў, тэсціроўшчыкаў і падтрымку.
Падтрымка і распрацоўка ў такім падыходзе не розныя аддзелы са сваімі мэтамі і задачамі. Распрацоўка ўцягнута ў эксплуатацыю і наадварот. Знакамітая фраза размеркаваных калектываў: «Праблема не на маім боку» ужо не так часта мільгае ў чатах, і канчатковыя карыстачы становяцца кропельку шчаслівей.
Крыніца: habr.com