Случајности су случајне, и заиста је било на другој планети...
Желео бих да поделим три приче о успеху и неуспеху о томе како бацкенд програмер ради у тиму са администраторима.
Прво историја.
Веб студио, број запослених се може пребројати једном руком. Данас си лаиоут дизајнер, сутра си бекендер, прекосутра си админ. С једне стране, можете стећи огромно искуство. С друге стране, постоји недостатак компетентности у свим областима. Још се сећам првог радног дана, зелена сам, каже шеф: „Отвори кит“, али не знам шта је. Комуникација са администраторима је искључена, јер сами сте администратор. Хајде да размотримо предности и недостатке ове ситуације.
+ Сва моћ је у вашим рукама.
+ Нема потребе никога молити за приступ серверу.
+ Брзо време реакције у свим правцима.
+ Добро побољшава вештине.
+ Имајте потпуно разумевање архитектуре производа.
— Висока одговорност.
— Ризик од прекида производње.
— Тешко је бити добар специјалиста у свим областима.
Не занима ме, идемо даље
Друга прича.
Велика компанија, велики пројекат. Постоји одељење администрације са 5-7 запослених и неколико развојних група. Када дођете да радите у таквој компанији, сваки админ мисли да нисте дошли да радите на неком производу, већ да бисте нешто разбили. Ни потписани НДА ни избор на интервјуу не показују другачије. Не, овај човек је дошао овде са својим прљавим малим рукама да уништи нашу продукцију љубљења. Дакле, са таквом особом вам је потребан минимум комуникације; у најмању руку, можете бацити налепницу као одговор. Не одговарајте на питања о архитектури пројекта. Препоручљиво је не одобравати приступ док вођа тима не затражи. А кад затражи, вратиће га са још мање привилегија него што су тражили. Скоро сву комуникацију са таквим администраторима апсорбује црна рупа између развојног одељења и одељења администрације. Немогуће је брзо решити проблеме. Али не можете доћи лично - администратори су превише заузети 24/7. (Шта радиш све време?) Неке карактеристике перформанси:
- Просечно време имплементације у производњи је 4-5 сати
- Максимално време примене у производњи 9 сати
- За програмера, апликација у производњи је црна кутија, баш као и сам производни сервер. Колико их има укупно?
- Низак квалитет издања, честе грешке
- Програмер не учествује у процесу издавања
Па шта сам очекивао, наравно, нове људе не пуштају у производњу. Па, добро, пошто смо стекли стрпљење, почињемо да стичемо поверење других. Али из неког разлога, ствари нису тако једноставне са администраторима.
Чин 1. Администратор је невидљив.
Дан издања, програмер и администратор не комуницирају. Администратор нема питања. Али касније ћете разумети зашто. Администратор је принципијелна особа, нема месинџере, никоме не даје свој број телефона и нема профил на друштвеним мрежама. Нигде нема ни његове фотографије, на шта личиш човјече? Седимо са одговорним менаџером око 15 минута у недоумици, покушавајући да успоставимо комуникацију са овим Воиагером 1, а онда се у корпоративном имејлу појављује порука да је завршио. Хоћемо ли се дописивати поштом? Што да не? Згодно, зар не? Па, добро, да се охладимо. Процес је већ у току, нема повратка. Прочитајте поруку поново. "Завршио сам". Шта си завршио? Где? Где да те тражим? Овде разумете зашто је 4 сата за ослобађање нормално. Добијамо развојни шок, али завршавамо издање. Више нема жеље за ослобађањем.
Чин 2. Не та верзија.
Следеће издање. Стекавши искуство, почињемо да правимо листе потребног софтвера и библиотека за сервер за администраторе, наводећи верзије за неке. Као и увек, добијамо слаб радио сигнал да је администратор нешто завршио тамо. Почиње тест регресије, који сам по себи траје око сат времена. Чини се да све функционише, али постоји једна критична грешка. Важна функционалност не ради. Следећих неколико сати било је плесање уз тамбураше, гатање на талогу од кафе и детаљан преглед сваког дела кода. Администратор каже да је све урадио. Апликација коју су написали покварени програмери не ради, али сервер ради. Има ли питања за њега? На крају једног сата добијамо од администратора да пошаље верзију библиотеке на производном серверу у ћаскање и бинго - није она која нам треба. Тражимо од администратора да инсталира потребну верзију, али у одговору добијамо да то не може учинити због одсуства ове верзије у менаџеру пакета ОС. Овде, из скровишта свог памћења, менаџер се сећа да је други администратор већ решио овај проблем једноставним ручним склапањем потребне верзије. Али не, наши то неће учинити. Прописи забрањују. Карл, седимо овде неколико сати, колико је временско ограничење?! Добијамо још један шок и некако завршимо издање.
Трећи чин, кратак
Хитна карта, кључна функционалност не ради за једног од корисника у продукцији. Проводимо пар сати боцкајући и проверавајући. У развојном окружењу све функционише. Постоји јасно разумевање да би било добро погледати пхп-фпм дневнике. У то време на пројекту није било система дневника као што су ЕЛК или Прометхеус. Отварамо тикет у одељењу администрације да нам дају приступ пхп-фпм логовима на серверу. Овде морате да схватите да тражимо приступ са разлогом, зар се не сећате да су црна рупа и администратори заузети 24/7? Ако их замолите да погледају саме дневнике, онда је ово задатак са приоритетом „не у овом животу“. Карта је направљена, добили смо тренутни одговор од шефа административног одељења: „Не треба вам приступ евиденцијама производње, пишите без грешака.“ Завеса.
Чин 4 и даље
Још увек прикупљамо десетине проблема у продукцији, због различитих верзија библиотека, неконфигурисаног софтвера, неприпремљеног оптерећења сервера и других проблема. Наравно, постоје и грешке у коду, нећемо кривити администраторе за све грехе, само ћемо поменути још једну типичну операцију за тај пројекат. Имали смо доста позадинских радника који су покренути преко супервизора, а неке скрипте су морале да се додају у црон. Понекад су ти исти радници престајали да раде. Оптерећење сервера за редове је расло муњевитом брзином, а тужни корисници су гледали у утоваривач који се окреће. Да бисте брзо поправили такве раднике, било је довољно једноставно их поново покренути, али опет, само администратор је то могао да уради. Док се радила таква основна операција, могао је да прође цео дан. Овде, наравно, вреди напоменути да би покварени програмери требало да напишу раднике да се не сруше, али када падну, било би лепо разумети зашто, што је понекад немогуће због недостатка приступа производњи, од наравно, и као последица тога, недостатак дневника од програмера.
Преображење.
Издржавши све ово доста дуго, заједно са екипом смо кренули у правцу који је за нас био успешнији. Да резимирамо, са којим проблемима смо се суочили?
- Недостатак квалитетне комуникације између програмера и администрације
- Администратори, испоставило се (!), уопште не разумеју како је апликација структурисана, које зависности има и како функционише.
- Програмери не разумеју како производно окружење функционише и, као резултат, не могу ефикасно да одговоре на проблеме.
- Процес постављања траје предуго.
- Нестабилна издања.
Шта смо урадили?
За свако издање генерисана је листа напомена о издању, која је укључивала листу послова који треба да се обави на серверу да би следеће издање функционисало. Листа је садржала неколико секција, посао који би требало да обавља администратор, особа одговорна за издање и програмер. Програмери су добили не-роот приступ свим производним серверима, што је убрзало развој уопште, а посебно решавање проблема. Програмери такође имају разумевање како продукција функционише, на које услуге је подељена, где и колико коштају реплике. Нека борбена оптерећења су постала јаснија, што несумњиво утиче на квалитет кода. Комуникација током процеса објављивања одвијала се у ћаскању једног од инстант мессенгер-а. Прво, имали смо дневник свих акција, а друго, комуникација се одвијала у ближем окружењу. Поседовање историје акција је више пута омогућило новим запосленима да брже решавају проблеме. То је парадокс, али то је често помогло самим администраторима. Нећу се обавезати да кажем са сигурношћу, али чини ми се да су администратори почели више да разумеју како пројекат функционише и како је написан. Понекад смо чак делили неке детаље једни са другима. Просечно време пуштања је смањено на сат времена. Понекад смо завршили за 30-40 минута. Број грешака се значајно смањио, ако не и десет пута. Наравно, и други фактори су утицали на смањење времена објављивања, као што су аутотестови. После сваког издања почели смо да водимо ретроспективе. Тако да цео тим има идеју шта је ново, шта је промењено, а шта је уклоњено. Нажалост, админи нису увек долазили код њих, па, админи су заузети... Моје задовољство послом као програмера је несумњиво порасло. Када можете брзо да решите скоро сваки проблем који је у вашој области ется сте на врхунцу. Касније ћу схватити да смо донекле увели девопс културу, не у потпуности, наравно, али је и тај почетак трансформације био импресиван.
Прича три
Покренути. Један администратор, мало одељење за развој. По доласку сам потпуна нула, јер... Немам приступ нигде осим са поште. Пишемо администратору и тражимо приступ. Поред тога, постоје информације да је упознат са новим запосленим и потребом за издавањем логина/лозинки. Они дају приступ из спремишта и ВПН-а. Зашто дати приступ викију, теамцити-у, рундеск-у? Бескорисне ствари за особу која је позвана да напише цео бацкенд део. Тек временом добијамо приступ неким алатима. Долазак је, наравно, дочекан са неповерењем. Покушавам полако да добијем осећај како инфраструктура пројекта функционише кроз ћаскање и сугестивна питања. У суштини не препознајем ништа. Производња је иста црна кутија као и раније. Али више од тога, чак и сценски сервери који се користе за тестирање су црна кутија. Не можемо ништа друго осим да тамо поставимо грану из Гита. Такође не можемо да конфигуришемо нашу апликацију као што су .енв датотеке. Приступ за такве операције није одобрен. Морате молити да промените ред у конфигурацији ваше апликације на тест серверу. (Постоји теорија да је од виталног значаја да се администратори осећају важним на пројекту; ако се од њих не тражи да промене редове у конфигурацијама, једноставно неће бити потребни). Па, као и увек, зар није згодно? Ово брзо постане досадно, након директног разговора са администратором сазнајемо да су програмери рођени да пишу лош код, по природи су некомпетентни појединци и да их је боље држати подаље од производње. Али овде и са тест сервера, за сваки случај. Сукоб брзо ескалира. Нема комуникације са администратором. Ситуацију отежава чињеница да је сам. Следеће је типична слика. Издање. Одређене функције не раде. Треба нам доста времена да схватимо шта се дешава, разне идеје програмера се убацују у ћаскање, али админ у таквој ситуацији обично претпоставља да су програмери криви. Онда пише у чет, чекај, исправио сам га. Када се замоли да оставимо причу са информацијама о томе шта је проблем, добијамо токсичне изговоре. Као, не гурај нос тамо где му није место. Програмери морају написати код. Изузетно је тужна ситуација када многи покрети тела у пројекту пролазе кроз једну особу и само она има приступ да изврши операције које су свима потребне. Таква особа је страшно уско грло. Ако Девопс идеје настоје да смање време за стављање на тржиште, онда су такви људи најгори непријатељ Девопс идеја. Нажалост, завеса се овде затвара.
ПС Након што сам мало причао о програмерима против администратора у ћаскању са људима, упознао сам људе који су делили мој бол. Али било је и оних који су рекли да се са нечим оваквим никада нису сусрели. На једној девопс конференцији питао сам Антона Исанина (Алфа банка) како се носе са проблемом уског грла у виду администратора, на шта је он рекао: „Заменили смо их дугмадима. Између осталог уз његово учешће. Волео бих да верујем да има много више добрих админа него непријатеља. И да, слика на почетку је права преписка.
Извор: ввв.хабр.цом