Зашто инжењери не брину о надгледању апликација?

Срећан петак свакоме! Пријатељи, данас настављамо серију публикација посвећених курсу „ДевОпс праксе и алати“, јер настава у новој групи за курс почиње крајем следеће недеље. Дакле, почнимо!

Мониторинг је само. Ово је позната чињеница. Покрените Нагиос, покрените НРПЕ на удаљеном систему, конфигуришите Нагиос на НРПЕ ТЦП порту 5666 и имате надзор.

Толико је лако да није занимљиво. Сада имате основне метрике за ЦПУ време, подсистем диска, РАМ, које се подразумевано испоручују за Нагиос и НРПЕ. Али ово заправо није „надгледање“ као такво. Ово је тек почетак.

(Обично инсталирају ПНП4Нагиос, РРДтоол и Тхрук, постављају обавештења у Слацк-у и иду директно на нагиосекцханге, али оставимо то за сада).

Добро праћење је заправо прилично сложена, заиста морате знати унутрашње елементе апликације коју надгледате.

Да ли је праћење тешко?

Сваки сервер, било да је то Линук или Виндовс, по дефиницији ће служити некој сврси. Апацхе, Самба, Томцат, складиште датотека, ЛДАП - све ове услуге су мање-више јединствене у једном или више аспеката. Сваки има своју функцију, своје карактеристике. Постоје различити начини да добијете метрике, КПИ (кључне индикаторе учинка), који су вам занимљиви када је сервер под оптерећењем.

Пхото би Луке Цхессер на Унспласх

(Волео бих да су моје контролне табле неонско плаве - сањиво уздишући -... хмм...)

Сваки софтвер који пружа услуге мора имати механизам за прикупљање метрике. Апацхе има модул mod-status, приказује страницу статуса сервера. Нгинк има - stub_status. Томцат има ЈМКС или прилагођене веб апликације које приказују кључне метрике. МиСКЛ има команду "прикажи глобални статус" итд.
Па зашто програмери не уграде сличне механизме у апликације које креирају?

Да ли то раде само програмери?

Одређени ниво равнодушности према уграђивању метрике није ограничен само на програмере. Радио сам у компанијама у којима су развијали апликације користећи Томцат и нису давали никакве сопствене метрике, никакве евиденције активности услуге, осим општих дневника грешака Томцат-а. Неки програмери генеришу много дневника који ништа не значе администратору система који нема среће да их прочита у 3:15 ујутру.

Пхото би Тим Гоув на Унспласх

Систем инжењери који омогућавају да се такви производи пуштају у продају такође морају сносити одређену одговорност за ситуацију. Мало системских инжењера има времена или бриге да покуша да извуче значајне метрике из евиденције, без контекста тих метрика и могућности да их интерпретира у светлу активности апликације. Неки не разумеју како могу да имају користи од тога, осим показатеља „нешто тренутно (или ће ускоро бити) погрешно“.

До промене у размишљању о потреби за метриком мора доћи не само међу програмерима, већ и међу системским инжењерима.

За сваког системског инжењера који треба не само да одговори на критичне догађаје, већ и да осигура да се они не догоде, недостатак метрике је обично препрека да то уради.

Међутим, системски инжењери се обично не петљају са кодом да би зарадили новац за своју компанију. Њима су потребни водећи програмери који разумеју важност одговорности системског инжењера у идентификовању проблема, подизању свести о проблемима перформанси и слично.

Ово девопс ствар

Девопс менталитет описује синергију између развојног (дев) и оперативног (опс) размишљања. Свака компанија која тврди да „ради девопс“ мора:

1. говоре ствари које вероватно не знају (позивајући се на мем принцезе невесте - "Мислим да то не значи оно што ви мислите да значи!")
2. Подстицати став о сталном побољшању производа.

Не можете побољшати производ и знати да је побољшан ако не знате како тренутно функционише. Не можете знати како производ функционише ако не разумете како његове компоненте функционишу, услуге од којих зависи, његове главне болне тачке и уска грла.
Ако не пазите на потенцијална уска грла, нећете моћи да следите технику Пет Зашто када пишете Постмортем. Нећете моћи да све поставите на један екран да бисте видели како производ функционише или да знате како изгледа „нормално и срећно“.

Схифт лево, ЛЕВО, САМ РЕКАО ЛЕЕЕЕ—

За мене, један од кључних принципа Девопса је „померање улево“. Померање улево у овом контексту значи померање могућности (нема одговорности, али само способности) да раде ствари до којих је системским инжењерима обично стало, као што је креирање метрика перформанси, ефикасније коришћење евиденција итд., са леве стране у животном циклусу испоруке софтвера.

Пхото би НЕСА од стране произвођача на Унспласх

Програмери софтвера морају бити у стању да користе и познају алате за праћење које компанија користи да би вршила надзор у свим његовим облицима, метрику, евидентирање, интерфејсе за праћење и, што је најважније, гледајте како њихов производ функционише у производњи. Не можете натерати програмере да уложе труд и време у надгледање док не виде метрике и утичу на то како изгледају, како их власник производа представља ЦТО-у на следећем брифингу итд.

Укратко речено

1. Води свог коња до воде. Покажите програмерима колико проблема могу да избегну за себе, помозите им да идентификују праве КПИ и метрике за своје апликације како би било мање викања од стране власника производа на кога ЦТО виче. Изнесите их на светлост, нежно и мирно. Ако то не успе, онда подмитите, претите и наговарајте или њих или власника производа да спроведу добијање ових метрика из апликација што је пре могуће, а затим нацртајте дијаграме. Ово ће бити тешко јер се неће посматрати као приоритет, а мапа пута ће имати много пројеката који генеришу приход на чекању. Због тога ће вам требати пословни случај да оправдате време и трошкове утрошене на имплементацију надзора у производ.
2. Помозите системским инжењерима да се добро наспају. Покажите им да је коришћење контролне листе „хајде да пустимо“ за било који производ који се издаје добра ствар. А осигурање да су све апликације у продукцији покривене метриком помоћи ће вам да боље спавате ноћу омогућавајући програмерима да виде шта иде наопако и где. Међутим, прави начин да изнервирате и фрустрирате било ког програмера, власника производа или техничког директора је да истрајете и одупрете се. Ово понашање ће утицати на датум објављивања било ког производа ако поново сачекате до последњег тренутка, па поново померите лево и унесите ове проблеме у план пројекта што је пре могуће. Ако је потребно, идите на састанке производа. Носите лажне бркове и филц или тако нешто, никада неће пропасти. Изнесите своје бриге, покажите јасне предности и евангелизујте.
3. Уверите се да и развој (дев) и операције (опс) разумеју значење и последице померања метрике производа у црвену зону. Не остављајте Опс као јединог чувара здравља производа, уверите се да су и програмери укључени (#продуцтскуадс).
4. Дневници су одлична ствар, али и метрика. Комбинујте их и не дозволите да вам трупци постану смеће у огромној пламеној кугли бескорисности. Објасните и покажите програмерима зашто нико други неће разумети њихове дневнике, покажите им како је гледати бескорисне дневнике у 3:15 ујутру.

Пхото би Марко Хорват на Унспласх

То је све. Нови материјал ће бити објављен следеће недеље. Уколико желите да сазнате више о курсу, позивамо вас да Отворен дан, који ће се одржати у понедељак. А сада већ традиционално чекамо ваше коментаре.

Извор: ввв.хабр.цом