Случајностите се случајни, и навистина беше на друга планета...
Би сакал да споделам три успешни и неуспешни приказни за тоа како развивачот на заднина работи во тим со администратори.
Приказна прва.
Веб студио, бројот на вработени може да се брои со една рака. Денес си layout designer, утре си backender, задутре си админ. Од една страна, можете да стекнете огромно искуство. Од друга страна, недостига компетентност во сите области. Сè уште се сеќавам на првиот работен ден, сè уште сум зелен, шефот вели: „Отвори кит“, но не знам што е тоа. Комуникацијата со администраторите е исклучена, бидејќи и самиот си админ. Ајде да ги разгледаме добрите и лошите страни на оваа ситуација.
+ Целата моќ е во ваши раце.
+ Нема потреба да молите никого за пристап до серверот.
+ Брзо време на реакција во сите правци.
+ Добро ги подобрува вештините.
+ Имајте целосно разбирање за архитектурата на производот.
- Висока одговорност.
- Ризик од кршење на производството.
- Тешко е да се биде добар специјалист во сите области.
Не ме интересира, да продолжиме понатаму
Втората приказна.
Голема компанија, голем проект. Има одделение за администрација со 5-7 вработени и неколку развојни групи. Кога доаѓаш да работиш во таква компанија, секој админ мисли дека не си дојден овде да работиш на некој производ, туку да скршиш нешто. Ниту потпишаната НДА, ниту изборот на интервјуто не укажуваат поинаку. Не, овој човек дојде овде со своите валкани мали раце да го уништи нашето производство на бакнување. Затоа, со таква личност ви треба минимум комуникација; во најмала рака, можете да фрлите налепница како одговор. Не одговарајте на прашања за архитектурата на проектот. Препорачливо е да не се дозволи пристап додека раководителот на тимот не побара. И кога ќе побара, ќе му врати со уште помалку привилегии отколку што барале. Речиси целата комуникација со таквите администратори се апсорбира од црната дупка помеѓу одделот за развој и одделот за администрација. Невозможно е да се решат проблемите навремено. Но, не можете да дојдете лично - администраторите се премногу зафатени 24/7. (Што правиш постојано?) Некои карактеристики на изведбата:
- Просечното време на распоредување во производството е 4-5 часа
- Максимално време на распоредување во производството 9 часа
- За развивач, апликацијата во производство е црна кутија, исто како и самиот производствен сервер. Колку ги има вкупно?
- Низок квалитет на изданија, чести грешки
- Инвеститорот не учествува во процесот на ослободување
Па, што очекував, се разбира, нови луѓе не се пуштаат во производство. Па, во ред, откако стекнавме трпение, почнуваме да ја стекнуваме довербата на другите. Но, поради некоја причина, работите не се толку едноставни со администраторите.
Акт 1. Админот е невидлив.
Ден на издавање, развивачот и администраторот не комуницираат. Админот нема прашања. Но, подоцна разбирате зошто. Админот е принципиелен човек, нема месинџери, никому не го дава својот телефонски број и нема профил на социјалните мрежи. Никаде нема ни фотографија од него, како изгледаш пријателе? Седиме со одговорниот менаџер околу 15 минути збунети, обидувајќи се да воспоставиме комуникација со овој Војаџер 1, а потоа во корпоративната е-пошта се појавува порака дека тој завршил. Ќе се допишуваме по пошта? Зошто да не? Погодно, нели? Па, во ред, ајде да се оладиме. Процесот е веќе во тек, враќање назад нема. Прочитајте ја пораката повторно. "Завршив". Што завршивте? Каде? Каде да те барам? Овде разбирате зошто 4 часа за ослободување се нормални. Добиваме развојен шок, но го завршуваме објавувањето. Веќе нема желба за ослободување.
Чин 2. Не таа верзија.
Следното издание. Имајќи стекнато искуство, започнуваме да создаваме списоци на потребниот софтвер и библиотеки за серверот за администратори, наведувајќи ги верзиите за некои. Како и секогаш, добиваме слаб радио сигнал дека админот завршил нешто таму. Започнува тестот за регресија, кој сам по себе трае околу еден час. Се чини дека сè работи, но има една критична грешка. Важна функционалност не работи. Следните неколку часа беа танцување со тамбураши, гатање на талог од кафе и детален преглед на секое парче код. Админот вели дека направил се. Апликацијата напишана од криви програмери не работи, но серверот работи. Дали има прашања за него? На крајот од еден час, го натераме администраторот да ја испрати верзијата на библиотеката на серверот за производство во разговорот и бингото - тоа не е онаа што ни треба. Бараме од администраторот да ја инсталира потребната верзија, но како одговор добиваме дека не може да го стори тоа поради отсуство на оваа верзија во менаџерот на пакети на ОС. Овде, од вдлабнатините на неговата меморија, менаџерот се сеќава дека друг админ веќе го решил овој проблем со едноставно составување на потребната верзија рачно. Но, не, нашите нема да го направат ова. Прописите забрануваат. Карл, седиме овде неколку часа, колку е рокот?! Добиваме нов шок и некако го завршуваме објавувањето.
Чин 3, кратко
Итен билет, клучната функционалност не работи за еден од корисниците во производството. Поминуваме неколку часа ѕиркајќи и проверувајќи. Во развојна средина, сè функционира. Постои јасно разбирање дека би било добра идеја да се погледне во дневниците php-fpm. Во тоа време на проектот немаше системи за дневници како ЕЛК или Прометеј. Отвораме билет до одделот за администрација, така што тие даваат пристап до дневниците php-fpm на серверот. Тука треба да разберете дека бараме пристап со причина, не се сеќавате ли дека црната дупка и администраторите се зафатени 24/7? Ако побарате од нив самите да ги погледнат дневниците, тогаш ова е задача со приоритет „не во овој живот“. Билетот беше создаден, добивме моментален одговор од раководителот на одделот за администрација: „Не треба да ви треба пристап до дневниците за производство, пишувајте без грешки“. Завеса.
Акт 4 и понатаму
Сè уште собираме десетици проблеми во производството, поради различни верзии на библиотеки, неконфигуриран софтвер, неподготвени оптоварувања на серверот и други проблеми. Се разбира, има и грешки во кодот, нема да ги обвинуваме администраторите за сите гревови, само ќе споменеме уште една типична операција за тој проект. Имавме доста работници во позадина кои беа лансирани преку супервизорот, а некои скрипти мораше да се додадат на cron. Понекогаш истите тие работници престанаа да работат. Оптоварувањето на серверот за чекање растеше со молскавична брзина, а тажните корисници гледаа во натоварувачот што се врти. За брзо да се поправат таквите работници, доволно беше едноставно да ги рестартирате, но повторно, само администраторот можеше да го стори тоа. Додека се правеше ваква основна операција, можеше да помине цел ден. Овде, се разбира, вреди да се напомене дека искривените програмери треба да пишуваат работници за да не паѓаат, но кога ќе паднат, би било убаво да се разбере зошто, што понекогаш е невозможно поради немањето пристап до производството, се разбира, и како последица на тоа, недостатокот на логови од инвеститорот.
Преображение.
Издржувајќи го сето тоа доста долго, заедно со тимот почнавме да се движиме во насока што беше поуспешна за нас. Да резимираме, со какви проблеми се соочивме?
- Недостаток на квалитетна комуникација помеѓу програмерите и одделот за администрација
- Администраторите, се испоставува(!), воопшто не разбираат како е структурирана апликацијата, какви зависности има и како функционира.
- Програмерите не разбираат како функционира производната средина и, како резултат на тоа, не можат ефикасно да одговорат на проблемите.
- Процесот на распоредување трае премногу долго.
- Нестабилни изданија.
Што направивме?
За секое издание, беше генерирана листа на Белешки за издавање, која вклучуваше листа на работа што треба да се изврши на серверот за следното издание да работи. Списокот содржеше неколку делови, работа што треба да ја изврши администраторот, лицето одговорно за објавувањето и развивачот. Програмерите добија не-root пристап до сите производствени сервери, што го забрза развојот воопшто, а особено решавањето на проблемите. Програмерите исто така имаат разбирање за тоа како функционира производството, на кои услуги е поделено, каде и колку чинат репликите. Некои од борбените оптоварувања станаа појасни, што несомнено влијае на квалитетот на кодот. Комуникацијата за време на процесот на ослободување се одвиваше во разговорот на еден од инстант-месинџерите. Прво, имавме дневник на сите дејствија, и второ, комуникацијата се одвиваше во поблиска средина. Имањето историја на активности повеќе од еднаш им овозможи на новите вработени побрзо да ги решаваат проблемите. Тоа е парадокс, но тоа често им помагаше на самите администратори. Нема да се обврзам да кажам со сигурност, но ми се чини дека администраторите почнаа да разбираат повеќе како функционира проектот и како е напишан. Понекогаш дури споделувавме некои детали едни со други. Просечното време на ослободување е намалено на еден час. Некогаш завршувавме за 30-40 минути. Бројот на бубачки е значително намален, ако не и десеткратно. Се разбира, други фактори исто така влијаеле на намалувањето на времето на ослободување, како што се автотестовите. По секое објавување, почнавме да спроведуваме ретроспективи. Така што целиот тим има идеја за тоа што е ново, што е променето и што е отстрането. За жал, админите не секогаш доаѓаа кај нив, добро, админите се зафатени... Моето задоволство од работата како програмер несомнено се зголеми. Кога можете брзо да го решите речиси секој проблем што е во вашата област на компетентност, се чувствувате на врвот. Подоцна, ќе разберам дека донекаде воведовме devops култура, не целосно, се разбира, но дури и тој почеток на трансформацијата беше импресивен.
Приказна трета
Почни. Еден админ, мал оддел за развој. По пристигнувањето сум целосна нула, бидејќи ... Немам пристап никаде освен од пошта. Пишуваме до администраторот и бараме пристап. Дополнително, има информации дека е запознаен со нововработениот и потребата од издавање најава/лозинки. Тие даваат пристап од складиштето и VPN. Зошто да дадете пристап до вики, тимски град, работна маса? Некорисни работи за човек кој бил повикан да го напише целиот бекенд дел. Само со текот на времето добиваме пристап до некои алатки. Пристигнувањето, се разбира, наиде на недоверба. Се обидувам полека да добијам чувство за тоа како функционира инфраструктурата на проектот преку разговори и водечки прашања. Во принцип, ништо не препознавам. Производството е истата црна кутија како порано. Но, повеќе од тоа, дури и серверите за фаза што се користат за тестирање се црна кутија. Не можеме да направиме ништо друго освен да распоредиме гранка од Git таму. Исто така, не можеме да ја конфигурираме нашата апликација како датотеките .env. Пристапот за такви операции не е одобрен. Мора да молите да се смени линијата во конфигурацијата на вашата апликација на серверот за тестирање. (Постои теорија дека е од витално значење за администраторите да се чувствуваат важни за проектот; ако од нив не се бара да менуваат линии во конфигурациите, тие едноставно нема да бидат потребни). Па, како и секогаш, зар не е погодно? Ова брзо станува досадно, по директен разговор со администраторот дознаваме дека програмерите се родени да пишуваат лош код, по природа се некомпетентни поединци и подобро е да се држат подалеку од производството. Но, тука и од тест сервери, за секој случај. Конфликтот брзо ескалира. Нема комуникација со админот. Ситуацијата ја влошува тоа што е сам. Следното е типична слика. Ослободете. Одредена функционалност не работи. Ни треба долго време да сфатиме што се случува, разни идеи од програмерите се фрлаат во разговорот, но администраторот во таква ситуација обично претпоставува дека програмерите се виновни. После пишува во муабетот чекај го исправив. Кога ќе побараме да оставиме приказна зад себе со информации за тоа што е проблемот, добиваме токсични изговори. Како, не лепете го носот каде што не му е местото. Програмерите мора да напишат код. Ситуацијата кога многу движења на телото во еден проект минуваат низ една личност и само тој има пристап да ги изврши операциите што им се потребни на сите е крајно тажна. Таквата личност е страшно тесно грло. Ако идеите на Devops се стремат да го намалат времето до пазар, тогаш таквите луѓе се најлошиот непријател на идеите на Devops. За жал, тука се затвора завесата.
П.С. Откако зборував малку за програмери наспроти администратори во разговори со луѓе, запознав луѓе кои ја споделија мојата болка. Но, имаше и такви кои рекоа дека никогаш не наишле на вакво нешто. На една конференција за devops, го прашав Антон Исанин (Алфа банка) како се справуваат со проблемот со тесното грло во форма на администратори, на што тој рече: „Ги заменивме со копчиња“. Патем со негово учество. Би сакал да верувам дека има многу повеќе добри админи отколку непријатели. И да, сликата на почетокот е вистинска кореспонденција.
Извор: www.habr.com