Што патрэбна для поспеху IT-кампаніі ў 2019 годзе? Лектары на канфах і мітапах кажуць шмат гучных і не заўсёды зразумелых нармальным людзям слоў. Барацьба за час дэплою, мікрасэрвісы, адмова ад маналіта, DevOps-трансфармацыя і шмат чаго яшчэ. Калі адкінуць слоўную прыгажосць і казаць прама і па-руску, тое ўсё зводзіцца да простай тэзы: рабіце якасны прадукт, прычым рабіце яго з камфортам для каманды.
Апошняе стала крытычна важна. Бізнэс нарэшце-то прыйшоў да думкі, што камфортны працэс распрацоўкі падвышае прадуктыўнасць, а калі ўсё адладжана і працуе як гадзіннік, то яшчэ і дае некаторую прастору для манеўру ў крытычных сітуацыях. Калісьці дзеля гэтага манеўру нейкі разумны чалавек прыдумаў бэкапы, але індустрыя развіваецца, і мы прыйшлі да DevOps-інжынераў - людзям, якія ператвараюць працэс узаемадзеяння распрацоўкі і знешняй інфраструктуры ў нешта адэкватнае і не звязанае з шаманізмам.
Уся гэтая гісторыя ад "па модулі" выдатная, але… Так атрымалася, што частка адмінаў рэзка ахрысцілі ў DevOps, а ад саміх DevOps-інжынераў сталі патрабаваць, прынамсі, навыкаў тэлепатыі і празорлівасці.
Перш чым казаць аб сучасных праблемах забеспячэння інфраструктуры, давайце вызначымся, што мы пад гэтым тэрмінам разумеем. На гэты момант сітуацыя склалася такім чынам, што мы выйшлі на дваістасць гэтага паняцця: інфраструктура можа быць умоўна знешняй і ўмоўна ўнутранай.
Пад знешняй інфраструктурай варта мець на ўвазе ўсё тое, што забяспечвае працаздольнасць сэрвісу або прадукта, распрацоўкай якой займаецца каманда. Гэта серверы прыкладання або сайта, хостынг і іншыя сэрвісы, якія забяспечваюць працаздольнасць прадукта.
Унутраная інфраструктура складаецца з сэрвісы і абсталяванне, якімі карыстаецца сама каманда распрацоўкі і іншыя супрацоўнікі, якіх звычайна таксама нямала. Гэта ўнутраныя серверы сістэм захоўвання кода, лакальна разгорнуты таск-мэнэджар і ўсё-ўсё-ўсё, што існуе ў рамках карпаратыўнага інтранэта.
Чым жа займаецца ў кампаніі сістэмны адміністратар? Акрамя працы па адміністраванні гэтага самага карпаратыўнага інтранэта, на ім часцяком ляжыць груз гаспадарчых клопатаў па забеспячэнні працаздольнасці офіснага абсталявання. Адмін - гэта той самы хлопец, які хутка прыцягне з падсобкі новы сістэмнік або гатовы да працы запасны наўтбук, выдасць свежую клавіятуру і будзе поўзаць на карачках па кабінетах, працягваючы Ethernet-кабель. Адмін – гэта лакальны гаспадар і валадар не толькі ўнутраных і вонкавых сервераў, але яшчэ і гаспадарнік. Так, некаторыя адміністратары могуць працаваць толькі ў сістэмнай плоскасці, без жалеза. Іх варта вылучыць у асобны падклас "інфраструктурных сістэмных адміністратараў". А хтосьці спецыялізуецца на абслугоўванні выключна офіснага абсталявання, балазе, калі кампанія налічвае больш за сотню чалавек, праца не канчаецца ніколі. Але ні тыя, ні іншыя дэвопсамі не з'яўляюцца.
А хто такія DevOps? Дэвопсы - гэта хлопцы, якія пра ўзаемадзеянне распрацоўкі праграмнага забеспячэння з знешняй інфраструктурай. Дакладней, сучасныя дэвапсы ўцягнутыя ў працэсы распрацоўкі і дэплою нашмат глыбей, чым былі калі-небудзь уцягнутыя адміны, проста якія залівалі апдэйты на ftp. Адна з ключавых задач DevOps-інжынера цяпер – гэта забеспячэнне камфортнага і эфектыўна выбудаванага працэсу ўзаемадзеяння каманд распрацоўкі і інфраструктуры прадукта. Менавіта гэтыя людзі адказныя за разгортванне сістэм адкатаў і дэплою, менавіта гэтыя людзі здымаюць частку нагрузкі з дэвелапераў і максімальна канцэнтруюцца на сваёй вельмі важнай задачы. Пры гэтым дэвопс ніколі не будзе працягваць новы кабель або выдаваць новы наўтбук з падсобкі (з) ДА
У чым падвох?
На пытанне "А хто такі DevOps?" палова работнікаў сферы пачынае адказваць нешта накшталт "Ну, гэта, карацей, такі адмін, які…" і далей па тэксце. Так, калісьці даўно, калі прафесія DevOps-інжынера толькі-толькі выпэцквалася з самых таленавітых у плане абслугоўвання сэрвісаў адмінаў, адрозненні паміж імі былі не ўсім відавочныя. Але цяпер, калі функцыі дэвопса і адміна ў камандзе сталі радыкальна адрознівацца, блытаць іх паміж сабой, а то і зусім ставіць паміж імі знак роўнасці - недапушчальна.
Але ў што гэта выліваецца для бізнэсу?
Найм, уся справа ў ім.
Вы адкрываеце вакансію "Сістэмны адміністратар", а там пералічаны патрабаванні "ўзаемадзеянне з распрацоўкай і заказчыкамі", "сістэма дастаўкі CI/CD", "абслугоўванне сервераў і абсталявання кампаніі", "адміністраванне ўнутраных сістэм" і гэтак далей; вы разумееце, што наймальнік нясе нейкую лухту. Падвох у тым, што замест "Сістэмны адміністратар" у загалоўку вакансіі павінна стаяць "DevOps-інжынер", і калі гэты загаловак памяняць, то ўсё становіцца на свае месцы.
Аднак якое ўражанне ствараецца пры чытанні такой вакансіі? Што кампанія шукае шматстаночніка, які і сістэму кантролю версій і маніторынгу разгорне, і вітуху абцісне зубамі.
А бо для таго, каб не падвышаць градус наркаманіі на рынку працы, досыць зваць вакансіі сваімі імёнамі і выразна разумець, што DevOps-інжынер і сістэмны адміністратар - гэта дзве розныя сутнасці. Вось толькі несуцішнае жаданне некаторых працадаўцаў прад'явіць да кандыдата як мага шырэйшы спіс патрабаванняў прыводзіць да таго, што «класічныя» сістэмныя адміністратары перастаюць разумець, што адбываецца вакол іх. Што, прафесія муціруе і яны адсталі ад жыцця?
Не, не і яшчэ раз не. Інфраструктурныя адміны, якія будуць руліць унутранымі серверамі кампаніі, ці займаць пазіцыі L2/L3-саппорта і дапамагаць іншым супрацоўнікам, нікуды не дзеліся і дзявацца не збіраюцца.
А ці могуць гэтыя спецыялісты стаць DevOps-інжынерамі? Канечне, могуць. Па факце, гэта роднаснае ім асяроддзе, якое патрабуе навыкаў сістэмнага адміністравання, але акрамя гэтага, дадаецца праца з маніторынгам, сістэмамі дастаўкі і, у цэлым, шчыльнае ўзаемадзеянне з камандай распрацоўкі і тэсціравання.
Яшчэ адна праблема DevOps
Насамрэч, толькі наймам і сталай блытанінай паміж адмінамі і дэвопсамі ўсё не абмяжоўваецца. У нейкі момант бізнэс сутыкнуўся з праблемай дастаўкі абнаўленняў і ўзаемадзеяння каманды распрацоўкі з канчатковай інфраструктурай.
Магчыма, гэта было тады, калі на сцэну нейкай канферэнцыі падняўся дзядзька з палаючымі вачыма і сказаў: «А мы робім вось так і называем гэта DevOps. Гэтыя хлопцы вырашаць усе вашыя праблемы» - і пачаў распавядаць, як добра жывецца ў кампаніі пасля ўкаранення DevOps-практык.
Аднак недастаткова наняць DevOps-інжынера для таго, каб усё стала працаваць "як трэба". Кампанія павінна цалкам прайсці DevOps-трансфармацыю, гэта значыць роля і магчымасці нашага девопса павінны выразна ўсведамляць яшчэ і на баку каманды распрацоўкі і тэставанні прадукта. На гэтую тэму ў нас ёсць «выдатная» гісторыя, якая ў поўнай меры ілюструе ўсю, якая адбываецца месцамі бляха.
Сітуацыя. Ад дэвопсу патрабуюць разгарнуць сістэму адкату версій, асабліва не ўнікаючы, як яна будзе працаваць. Выкажам здагадку, усярэдзіне сістэмы Users - гэта асобныя палі пад імя, прозвішча і пароль. Выходзіць новая версія прадукта, але для распрацоўшчыкаў «адкат» - гэта проста чароўная палачка, якая ўсё паправіць, і яны нават не ўяўляюць, як яна працуе. Дык вось, напрыклад, распрацоўшчыкі ў чарговым патчы аб'ядналі палі імя і прозвішчы, выкацілі гэта ў прод, а версія тармозіць па нейкіх прычынах. Што адбываецца? Кіраўніцтва прыходзіць да дэвапса і кажа "Дрыгай рубільнік!", гэта значыць просіць яго адкаціцца на папярэднюю версію. Што робіць дэвопс? Ён адкочваецца на папярэднюю версію, але бо распрацоўшчыкі не захацелі разбірацца, як робіцца гэты адкат, то ніхто дэвапсу не сказаў, што адкаціць трэба яшчэ і базу. У выніку ў нас падае наогул усё, і карыстачы замест які тармозіць сайта бачаць памылку «500», таму што старая версія не працуе з палямі новай базы. Дэвапс аб гэтым не ў курсе. Распрацоўнікі маўчаць. Кіраўніцтва пачынае губляць нервы і грошы і ўспамінае пра бэкапы, прапаноўваючы адкаціцца з іх, каб «хоць што-небудзь ды працавала». У выніку карыстачы губляюць усе свае дадзеныя за нейкі прамежак часу.
На арэхі дастаецца, вядома ж, дэвапсу, які "не зрабіў правільную сістэму адкату", а тое што ласі ў гэтай гісторыі - распрацоўшчыкі, нікога не хвалюе.
Выснова простая: без нармальнага падыходу да DevOps як такога толку ад яго не вельмі шмат.
Галоўнае, што трэба памятаць: DevOps-інжынер - не чараўнік, і без якасных камунікацый і двухбаковага ўзаемадзеяння з распрацоўкай ён не будзе спраўляцца са сваімі задачамі. Дэвопсаў нельга пакінуць сам-насам з іх "праблемамі" або даць каманду "не лезь да распрацоўнікаў, іх справа кадзіць", а потым спадзявацца, што ў крытычны момант усё будзе працаваць, як трэба. Дык гэта не працуе.
Па сутнасці, DevOps – гэта кампетэнцыі на мяжы паміж мэнэджментам і тэхналогіямі. Прычым, далёка не відавочна, што ў гэтым кактэйлі тэхналогій павінна быць больш, чым мэнэджменту. Калі вы сапраўды хочаце пабудаваць больш хуткія і эфектыўныя працэсы распрацоўкі, вы павінны давяраць свайму дэвапсу. Ён ведае патрэбныя інструменты, ён рэалізоўваў такія праекты, ён ведае, як рабіць. Дапамажыце яму, прыслухайцеся да яго парад, не спрабуйце ізаляваць у нейкае аўтаномнае падраздзяленне. Калі адміны могуць працаваць самі па сабе, то дэвапсы ў такім выпадку бескарысныя, яны не змогуць дапамагчы вам стаць лепш, калі вы самі не захочаце гэтую дапамогу прыняць.
Ну і апошняе: хопіць крыўдзіць адміністратараў-інфраструктуршчыкаў. У іх свой, вельмі важны фронт прац. Так, адмін можа стаць DevOps-інжынерам, але гэта павінна адбывацца па жаданні самога чалавека, а не з-пад палкі. І няма нічога дрэннага ў тым, што сістэмны адміністратар хоча застацца сістэмным адміністратарам - гэта яго асобная прафесія і яго права. Калі ж ёсць жаданне прайсці прафесійную трансфармацыю, то трэба ні ў якім разе не забываць, што нарошчваць давядзецца не толькі тэхналагічныя навыкі, але яшчэ і кіраўнічыя. Усіх гэтых людзей зводзіць разам і вучыць размаўляць на адной мове, хутчэй за ўсё, давядзецца менавіта вам як кіраўніку.
Крыніца: habr.com