Здраво, Хабр! Већ десет година подржавам Хигхлоад ИТ системе. Нећу писати у овом чланку о проблемима подешавања нгинк-а да ради у 1000+ РПС режиму или другим техничким стварима. Изнећу своја запажања о проблемима у процесима који се јављају у подршци и раду оваквих система.
Праћење
Техничка подршка не чека да стигне захтев са садржајем „Шта зашто... сајт поново не ради?“ У року од једног минута након пада сајта, подршка би већ требало да види проблем и почне да га решава. Али сајт је врх леденог брега. Његова доступност је једна од првих која се прати.
Шта учинити са ситуацијом када преостала роба онлине продавнице више не стиже из ЕРП система? Или је ЦРМ систем који обрачунава попусте за клијенте престао да одговара? Изгледа да сајт ради. Условни Заббик добија свој 200 одговор. Дежурна смена није добила никаква обавештења од мониторинга и са задовољством гледа прву епизоду нове сезоне Игре престола.
Надгледање је често ограничено само на мерење стања меморије, РАМ-а и оптерећења процесора сервера. Али за пословање је много важније доступност производа на веб локацији. Условни квар једне виртуелне машине у кластеру довешће до тога да ће саобраћај престати да иде до ње, а оптерећење на другим серверима ће се повећати. Компанија неће изгубити новац.
Због тога, поред праћења техничких параметара оперативних система на серверима, потребно је да конфигуришете пословну метрику. Мере које директно утичу на новац. Различите интеракције са екстерним системима (ЦРМ, ЕРП и други). Број поруџбина за одређени временски период. Успешне или неуспешне ауторизације клијената и други показатељи.
Интеракција са спољним системима
Било која веб локација или мобилна апликација са годишњим прометом већим од милијарду рубаља комуницира са спољним системима. Почевши од горе наведених ЦРМ-а и ЕРП-а па до трансфера података о продаји у екстерни Биг Дата систем за анализу куповина и нуђење клијенту производа који ће сигурно купити (у ствари, не). Сваки такав систем има своју подршку. И често комуникација са овим системима изазива бол. Нарочито када је проблем глобалан и морате га анализирати у различитим системима.
Неки системи дају телефонски број или телеграм за своје администраторе. Негде треба да пишете писма менаџерима или да одете на трагаче грешака ових спољних система. Чак иу контексту једне велике компаније, различити системи често функционишу у различитим рачуноводственим системима апликација. Понекад постаје немогуће пратити статус апликације. Добијате захтев у једном условном Јира. Онда сте у коментару овог првог Јира-а ставили линк до проблема у другом Јира-у. У другом Ћира у апликацији неко већ пише коментар који потребно је да позовете условног администратора Андреја да решите проблем. И тако даље.
Најбоље решење за овај проблем би било стварање јединственог простора за комуникацију, на пример у Слацк-у. Позивање свих учесника у процесу рада екстерних система да се придруже. И такође један трагач како не би дуплицирали апликације. Апликације треба пратити на једном месту, од праћења обавештења до излаза решења за грешке у будућности. Рећи ћете да је то нереално и историјски се дешавало да ми радимо у једном трекеру, а они у другом. Појавили су се различити системи, имали су своје аутономне ИТ тимове. Слажем се и стога проблем треба да се реши одозго на нивоу ЦИО или власника производа.
Сваки систем са којим комуницирате треба да пружи подршку као услугу са јасним СЛА за решавање проблема по приоритету. А не када условни администратор Андреј има минут за вас.
Боттленецк Ман
Да ли свако на пројекту (или производу) има особу чији одлазак на одмор изазива грчеве код надређених? Ово може бити девопс инжењер, аналитичар или програмер. На крају крајева, само девопс инжењер зна који сервери имају инсталиране контејнере, како да рестартују контејнер у случају проблема, и уопште, ниједан сложен проблем не може се решити без њега. Аналитичар је једини који зна како функционише ваш сложени механизам. Који токови података где иду. Под којим параметрима захтева на које услуге, на које ћемо добити одговоре.
Ко ће брзо схватити зашто постоје грешке у евиденцији и одмах поправити критичну грешку у производу? Наравно, исти програмер. Има и других, али из неког разлога само он разуме како функционишу различити модули система.
Корен овог проблема је недостатак документације. На крају крајева, када би се описали све услуге вашег система, онда би било могуће решити проблем без аналитичара. Ако би девопс одвојио пар дана од свог заузетог распореда и описао све сервере, сервисе и упутства за решавање типичних проблема, онда би проблем у његовом одсуству могао да се реши без њега. Не морате брзо да завршите своје пиво на плажи док сте на одмору и тражите Ви-Фи да бисте решили проблем.
Компетентност и одговорност помоћног особља
На великим пројектима компаније не штеде на платама програмера. Траже скупе средње или старије особе из сличних пројеката. Са подршком ситуација је мало другачија. Они на све начине покушавају да смање ове трошкове. Компаније ангажују јефтине јучерашње Еникеи раднике и храбро крећу у битку. Ова стратегија је могућа ако говоримо о веб страници визиткарте фабрике у Зеленограду.
Ако говоримо о великој онлајн продавници, онда сваки сат застоја кошта више од месечне плате Еникеи администратора. Узмимо за полазну тачку 1 милијарду рубаља годишњег промета. Ово је минимални промет било које онлине продавнице из рејтинга . Поделите овај износ са бројем сати годишње и добијте више од 100 рубаља нето губитака. А ако не рачунате ноћне сате, можете безбедно да удвостручите износ.
Али новац није главна ствар, зар не? (не, наравно главна ствар) Постоје и губици угледа. Пропаст познате онлине продавнице може изазвати како талас критика на друштвеним мрежама, тако и публикације у тематским медијима. А разговори пријатеља у кухињи у стилу „Не купујте ништа тамо, њихов сајт увек не ради“ никако се не могу мерити.
Сада на одговорност. У мојој пракси је био случај да дежурни администратор није на време одговорио на обавештење система за праћење о недоступности сајта. Једног пријатног летњег петка увече, сајт познате интернет продавнице у Москви је мирно лежао. У суботу ујутру, менаџер производа овог сајта није разумео зашто се сајт не отвара, а у Слацк-у је владала тишина у разговорима за подршку и хитна обавештења. Таква грешка нас је коштала шестоцифрене суме, а овог дежурног посла.
Одговорност је вештина која се тешко развија. Или га особа има или не. Стога, током интервјуа, покушавам да идентификујем његово присуство разним питањима која индиректно показују да ли је особа навикла да преузме одговорност. Ако човек одговори да је изабрао факултет јер су му родитељи тако рекли или промени посао јер му је жена рекла да не зарађује довољно, онда је боље да се не петља са таквим људима.
Интеракција са развојним тимом
Када корисници наиђу на једноставне проблеме са производом током рада, подршка их решава сама. Покушава да репродукује проблем, анализира евиденције и тако даље. Али шта учинити када се грешка појави у производу? У овом случају, подршка додељује задатак програмерима и ту почиње забава.
Програмери су стално преоптерећени. Они стварају нове карактеристике. Исправљање грешака са продајом није најзанимљивија активност. Приближавају се рокови за завршетак следећег спринта. А онда дођу непријатни људи из подршке и кажу: „Одмах престаните са свиме, имамо проблема“. Приоритет таквих задатака је минималан. Нарочито када проблем није најкритичнији и главна функционалност сајта функционише, и када менаџер издања не трчи около избуљених очију и не пише: „Хитно додајте овај задатак следећем издању или хитној исправци.“
Проблеми са нормалним или ниским приоритетом се премештају из издања у издање. На питање „Када ће задатак бити завршен?“ добићете одговоре у стилу: „Извините, тренутно има пуно задатака, питајте вође тима или менаџера за издавање.“
Проблеми са продуктивношћу имају већи приоритет од стварања нових функција. Лоше критике неће дуго чекати ако корисници стално наиђу на грешке. Нарушену репутацију је тешко вратити.
Питања интеракције између развоја и подршке решава ДевОпс. Ова скраћеница се често користи у облику одређене особе која помаже у стварању тестних окружења за развој, гради ЦИЦД цевоводе и брзо доводи тестирани код у производњу. ДевОпс је приступ развоју софтвера када сви учесници у процесу блиско комуницирају једни са другима и помажу у брзом креирању и ажурирању софтверских производа и услуга. Мислим на аналитичаре, програмере, тестере и подршку.
У овом приступу подршка и развој нису различита одељења са сопственим циљевима и задацима. Развој је укључен у рад и обрнуто. Чувена фраза дистрибуираних тимова: „Проблем није на мојој страни“ више се не појављује тако често у четовима, а крајњи корисници постају мало срећнији.
Извор: ввв.хабр.цом