Супадзенні выпадковыя, ды і ўвогуле гэта было на іншай планеце…
Жадаю падзяліцца трыма гісторыямі поспеху і няўдачы аб тым як працуецца бэкенд распрацоўніку ў камандзе з адмінамі.
Гісторыя першая.
Вэб студыя, колькасць супрацоўнікаў паддаецца рахунку адной рукой. Сёння ты вярстальнік, заўтра бекендэр, паслязаўтра адмін. З аднаго боку, можна атрымаць каласальны досвед. З іншага, не хапае кампетэнцыі ва ўсіх абласцях. Да гэтага часу памятаю першы працоўны дзень, я яшчэ зялёны, начальнік кажа: «Адчыняй putty», а я не ведаю, што гэта такое. Зносіны з адмінамі выключана, т.я. ты сам адмін. Разгледзім плюсы і мінусы такога становішча.
+ Уся ўлада ў тваіх руках.
+ Не трэба ні ў каго клянчыць доступы ад сервера.
+ Хуткае час рэакцыі па ўсіх напрамках.
+ Добра прапампоўвае скілы.
+ Ёсць поўнае разуменне архітэктуры прадукта.
- Высокая адказнасць.
— Рызыка паламаць прадакшэны.
- Складана быць добрым спецыялістам ва ўсіх абласцях.
Не цікава, ідзем далей
Гісторыя другая.
Буйная кампанія, буйны праект. Ёсць аддзел адміністравання з 5-7 супрацоўнікамі і некалькі груп распрацоўкі. Калі прыходзіш працаваць у такую кампанію, кожны адмін лічыць, што ты прыйшоў сюды не працаваць над прадуктам, а нешта зламаць. Ні падпісанае NDA, ні адбор на сумоўі не кажа пра адваротнае. Не, гэты чалавек прыйшоў сюды сваімі бруднымі ручкамі сапсаваць наш цалаваны прадакшэн. Таму з такім чалавекам трэба мінімум зносін, на крайняк можна кінуць стыкер у адказ. На пытанні аб архітэктуры праекту не адказваць. Пажадана не выдаваць доступы пакуль тымлід не папросіць. А калі папросіць, выдаць з яшчэ меншымі прывілеямі чым прасілі. Практычна ўся камунікацыя з такімі адмінамі паглынаецца чорнай дзіркай паміж аддзелам распрацоўкі і аддзелам адміністравання. Вырашыць пытанні аператыўна немагчыма. А падысці асабіста нельга - адміны занадта занятыя 24/7. (Чым вы ўвесь час занятыя?) Некаторыя ТТХ:
- Сярэдні час дэплою ў прадакшэн 4-5ч
- Максімальны час дэплою ў прадакшэн 9ч
- Для распрацоўніка прыкладанне ў прадакшэне гэта чорная скрыня, як і сам сервер прадакшэну. А колькі іх увогуле?
- Нізкая якасць рэлізаў, частыя памылкі
- Распрацоўнік не прымае ўдзелу ў працэсе рэлізу
Ну а што я чакаў, вядома на прадакшэн новенькіх не пускаюць. Ну ды добра, набраўшыся цярпення пачынаем атрымліваць давер у навакольных. Але чамусьці з адмінамі не ўсё так проста.
Акт 1. Адмін невідзімка.
Дзень рэлізу, распрацоўшчык і адмін не маюць зносін. У адміна няма ніякіх пытанняў. Але чаму разумееш пазней. Адмін прынцыповая асоба, не мае месэнджараў, нумар тэлефона нікому не дае, профіля ў сацсетках не мае. Ды нават фота яго нідзе няма, як ты выглядаеш чувак? Сядзім з адказным мэнэджэрам хвілін 15 у здзіўленні, спрабуем наладзіць сувязь з гэтым «Вояджэр-1», тут на карпаратыўную пошту падае паведамленне, што ён скончыў. Мы што па пошце будзем перапісвацца? А чаму б не? Зручна, ці не праўда? Ну ды добра, астынем. Працэс ужо ідзе, назад дарогі няма. Чытаем яшчэ раз паведамленне. "Я скончыў". А што ты скончыў? Дзе? Куды глядзець каб цябе? Тут вы разумееце, чаму 4ч на рэліз гэта нармальна. Атрымліваем распрацоўчы шок, але рэліз заканчваем. Жадання рэлізавацца больш няма.
Акт 2. Не тая версія.
Чарговы рэліз. Панабраўшыся досведу, мы пачынаем фармаваць спісы неабходнага софту і бібліятэк на сервер для адмінаў, з указаннем версій для некаторых. Як заўсёды, атрымліваем слабы радыёсігнал, што адмін нешта там скончыў. Пачынаецца рэгрэсійны тэст, які сам па сабе займае каля гадзіны. Быццам бы ўсё працуе, але ёсць адзін крытычны баг. Важная функцыянальнасць не працуе. Наступныя некалькі гадзін танцы з бубнамі, варажба на кававай гушчы, дэталёвы перагляд кожнага кавалка кода. Адмін кажа, што ўсё зрабіў. Не працуе ж прыкладанне напісанае крыварукімі распрацоўшчыкамі, а сервер працуе. Якія да яго пытанні. На зыходзе нейкай гадзіны такі дамагаемся ад адміна, каб той скінуў у чат версію бібліятэкі на прадакшэн серверы і Бінга - яна не тая, што патрэбна. Просім адміна паставіць патрэбную версію, у адказ атрымліваем, што ён гэтага зрабіць не можа па чынніку адсутнасці гэтай версіі ў пакетным мэнэджары АС. Тут з засекаў памяці мэнэджар успамінае, што іншы адмін ужо вырашаў гэтую праблему, проста сабраўшы патрэбную версію рукамі. Але не, наш гэтага рабіць не стане. Рэгламент забараняе. Карл мы ўжо некалькі гадзін сядзім, які рэгламент?! Атрымліваем чарговы шок, рэліз сяк-так заканчваем.
Акт 3, кароткі
Тэрміновы тыкет, на прадакшэне не працуе ключавы функцыянал у аднаго з карыстальнікаў. Пару гадзін тыкаем, правяраем. У дэвэлап асяроддзі ўсё працуе. Ёсць дакладнае разуменне, што нядрэнна б зазірнуць у логі php-fpm. Сістэмы для логаў накшталт ELK ці Prometheus у той час на праекце не было. Заводзім тыкет на аддзел адміністравання, каб тыя далечы доступ да логаў php-fpm на сервер. Тут трэба разумець, што доступ просім не з простай, вы ж памятаеце пра чорную дзірку і занятасць адмінаў 24/7? Калі папрасіць іх паглядзець логі самім, то гэта задача з прыярытэтам "не ў гэтым жыцці". Тыкет створаны, атрымліваем маментальны адказ ад кіраўніка аддзела адміністравання: "Вам не павінен быць патрэбен доступ да логаў на прадакшэне, пішыце без багаў". Заслону.
Акт 4 і наступныя
Збіраны яшчэ ні адзін дзясятак праблем на прадакшэне, з-за розных версій бібліятэк, не наладжанага па, непадрыхтаванага да нагрузак сервера і іншых праблем. Кодавыя багі вядома таксама бываюць, не будзем ва ўсіх грахах вінаваціць адмінаў, згадаем толькі яшчэ адну тыповую аперацыю для таго праекту. Было ў нас дастаткова шмат фонавых воркераў, якія запускаліся праз супервізор, а некаторыя скрыпты трэба было дадаваць у cron. Часам гэтыя самыя воркеры пераставалі працаваць. На серверы чэргаў вокамгненна расла нагрузка, а грусныя карыстачы глядзелі на крутоўны лодэр. Для хуткага папраўкі такія воркеры дастаткова было проста перазапусціць, але зноў жа зрабіць гэта мог толькі адмін. Пакуль такая элементарная аперацыя выконвалася, мог прайсці цэлы дзень. Тут вядома варта адзначыць, што крыварукія праграмісты павінны пісаць воркеры так каб яны не валіліся, але, калі яны зваліліся, нядрэнна бы разумець чаму, што часам немагчыма па чынніку адсутнасці доступаў на прадакшэн вядома жа і як следства адсутнасць логаў у распрацоўніка.
Праабражэння.
Пацярпеўшы гэта ўсё даволі працяглы час, сумесна з камандай мы пачалі руліць у больш паспяховае для нас рэчышча. Калі рэзюмаваць, якія перад намі стаялі праблемы?
- Адсутнасць якаснай камунікацыі паміж распрацоўшчыкамі і аддзелам адміністравання
- Адміны, аказваецца(!), зусім не разумеюць, як уладкована дадатак, якія ў яго залежнасці і як яно працуе.
- Распрацоўнікі не разумеюць, як уладкованае прадакшэнае асяроддзе і як следства не могуць эфектыўна рэагаваць на праблемы.
- Занадта працяглы час займае працэс дэплою.
- Нестабільныя рэлізы.
Што мы зрабілі?
Да кожнага рэлізу фармавалі спіс Release Notes, які ўключаў пералік прац, якія неабходна вырабіць на серверы, для працы чарговага рэлізу. Спіс змяшчаў некалькі секцый, працы, якія павінен правесці адміністратар, адказны за рэліз і распрацоўшчык. Распрацоўнікі атрымалі доступ (не root) на ўсе прадакшэны сервера, што паскорыла распрацоўку ў цэлым і рашэнне праблем у прыватнасці. Гэтак жа ў распрацоўшчыкаў з'явілася разуменне як уладкованы прадакшэн, на якія сэрвісы падзелены, дзе і колькі каштуе рэплік. Ад часткі сталі больш зразумелыя баявыя нагрузкі, што несумненна ўплывае на якасць кода. Зносіны ў працэсе рэлізу адбываліся ў чаце аднаго з месэнджараў. Па-першае, у нас з'яўляўся лог усіх дзеянняў, па-другое, зносіны адбываліся ў больш цесным асяроддзі. Наяўнасць гісторыі дзеянняў ні разоў дазваляла новым супрацоўнікам хутчэй вырашыць праблемы. Парадокс, але гэта часцей дапамагала самім адмінам. Я не вазьмуся сцвярджаць дакладна, але мне здаецца, што адміны сталі больш разумець, як уладкованы праект, як ён напісаны. Часам мы нават дзяліліся некаторымі дэталямі сябар з сябрам. Сярэдні час рэлізу скараціўся да гадзіны. Часам мы ўкладваліся за 30-40 хвілін. Колькасць багаў скарацілася ў разы, калі не ў дзясяткі разоў. Вядома на скарачэнне часу рэлізу ўплывалі і іншыя фактары, напрыклад, такія як аўтатэсты. Пасля кожнага рэлізу мы пачалі праводзіць рэтраспектывы. Каб уся каманда мела ўяўленне, што новага з'явілася, што змянілася, а што было ўбрана. Нажаль, адміны далёка не заўсёды на іх прыходзілі, ну адміны жа занятыя… Задаволенасць працай у мяне як у распрацоўніка несумнеўна падвысілася. Калі ты можаш вырашыць хутка практычна любую праблему, якая ў тваёй зоне кампетэнцыі, ты адчуваеш сябе на кані. Пазней, я зразумею, што мы ў нейкай ступені ўкаранілі дэвопс культуру, не цалкам вядома, але нават той пачатак трансфармацыі быў уражлівым.
Гісторыя трэцяя
Стартап. Адзін адмін, невялікі аддзел распрацоўшчыкаў. Па прыходзе я поўны нуль, т.я. акрамя як ад пошты доступаў у мяне нікуды няма. Пішам адміну, просім даць доступы. Да таго ж ёсць інфармацыя, што ён у курсе, новага супрацоўніка і неабходнасці ў выдачы лагінаў/пароляў. Даюць доступ ад рэпазітара і впн. Навошта даваць доступ да wiki, teamcity, rundesk? Бескарысныя рэчы для чалавека, якога паклікалі цалкам пісаць бэкенд частка. Толькі з часам атрымліваем доступ да некаторых прылад. Прыход вядома ж сустрэты недаверам. Спрабую паціху прамацаць як уладкованая інфраструктура праекту праз чаты і навадныя пытанні. У асноўным нічога не даведаюся. Прадакшаная такая ж чорная скрыня, як і раней. Але больш за тое, тут чорная скрыня нават stage сервера, якія выкарыстоўваюцца для тэставання. Акрамя дэплою туды галінкі з гіта мы нічога не можам. Гэтак жа мы не можам канфігураваць сваё прыкладанне накшталт .env файлаў. Доступ для такіх аперацый не пакладзены. Трэба займацца папрашайніцтвам каб табе памянялі радок у канфізе твайго прыкладання на тэставым серверы. (Ёсць тэорыя, што адмінам жыццёва неабходна пачувацца самымі важнымі на праекце, калі іх не будуць прасіць мяняць радкі ў канфігах, яны проста будуць не патрэбныя). Ну як заўсёды, ці не праўда зручна? Такое хутка надакучае, пасля прамой гутаркі з адмінам высвятляем, што распрацоўнікі нарадзіліся для таго каб пісаць дрэнны код, па прыродзе сваёй некампіентныя асобы і лепш іх трымаць далей ад прадакшэна. Але тут яшчэ і ад тэставых сервераў на ўсялякі выпадак. Канфлікт хутка набірае абароты. Камунікацыі з адмінам няма. Сітуацыя пагаршаецца тым, што ён адзін. Далей тыповая карціна. Рэліз. Не працуе пэўны функцыянал. Доўга разбіраемся ў чым справа, у чат накідваюцца розныя ідэі ад распрацоўшчыкаў, але адмін у такой сітуацыі як правіла зыходзіць, што вінаватыя распрацоўшчыкі. Потым піша ў чаце, стойце я паправіў. На просьбы пакінуць гісторыю пасля сябе з інфармацыяй у чым была праблема атрымліваем таксічныя адгаворкі. Маўляў, не совай свой нос куды не трэба. Распрацоўнікі павінны пісаць код. Сітуацыя, калі многія рухі цела ў праекце праходзяць праз аднаго адзінага чалавека і толькі ў яго ёсць доступы для здзяйснення патрэбных усім аперацый вельмі сумная. Такі чалавек жудаснае бутэлькавае рыльца. Калі ідэі Devops імкнуцца скараціць time-to-market, то такія людзі гэта злейшы вораг ідэй devops'a. Нажаль тут зачыняецца заслона.
PS Трохі пагутарыўшы на тэму распрацоўшчыкі vs адміны ў чатах з людзьмі, я сустрэў людзей, якія падзялілі мой боль. Але таксама былі і тыя, хто сказаў, што з такім не сутыкаўся. На адной devops канферэнцыі я пацікавіўся ў Антона Ісаніна (Альфа-банк) як яны змагаліся з праблемай бутэлькавага рыльца ў выглядзе адмінаў, на што ён сказаў: "Мы іх замянілі на кнопкі". Вось дарэчы з яго ўдзелам. Жадаецца верыць, што добрых адмінаў значна больш чым ворагаў. І так, карцінка ў пачатку гэта рэальная перапіска.
Крыніца: habr.com