Зошто инженерите не се грижат за следењето на апликациите?

Среќен петок на сите! Пријатели, денес ја продолжуваме серијата публикации посветени на курсот „Практики и алатки на DevOps“, бидејќи наставата во новата група за курсот ќе започне кон крајот на следната недела. Значи, да почнеме!

Мониторингот е само. Ова е познат факт. Поставете Nagios, стартувајте NRPE на далечинскиот систем, конфигурирајте Nagios на NRPE TCP портата 5666 и имате мониторинг.

Толку е лесно што не е интересно. Сега имате основна метрика за време на процесорот, потсистем на диск, RAM меморија, стандардно доставени до Nagios и NRPE. Но, ова всушност не е „следење“ како такво. Ова е само почетокот.

(Обично инсталираат PNP4Nagios, RRDtool и Thruk, поставуваат известувања во Slack и одат директно на nagiosexchange, но да го оставиме тоа засега).

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

Дали е тешко следењето?

Секој сервер, без разлика дали е Linux или Windows, по дефиниција ќе има одредена цел. Apache, Samba, Tomcat, складирање датотеки, LDAP - сите овие услуги се повеќе или помалку единствени во еден или повеќе аспекти. Секој има своја функција, свои карактеристики. Постојат различни начини за добивање метрика, KPI (клучни индикатори за перформанси), кои се интересни за вас кога серверот е под оптоварување.

Автор на фотографијата Лук Шасер на Unsplash

(Посакувам контролните табли да ми беа неонски сини - воздивнува со сон -... хм...)

Секој софтвер што обезбедува услуги мора да има механизам за собирање метрика. Apache има модул mod-status, прикажувајќи ја страницата за статус на серверот. Nginx има - stub_status. Tomcat има JMX или сопствени веб-апликации кои ги прикажуваат клучните метрики. MySQL има команда „покажи глобален статус“ итн.
Па зошто програмерите не вградуваат слични механизми во апликациите што ги создаваат?

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

Одредено ниво на рамнодушност кон вградувањето на метрика не е ограничено само на програмерите. Работев во компании каде што развиваа апликации користејќи Tomcat и не даваа никаква сопствена метрика, нема дневници за активност на услуги, освен општи дневници за грешки на Tomcat. Некои програмери генерираат многу дневници кои ништо не значат за системскиот администратор кој нема среќа да ги прочита во 3:15 часот наутро.

Автор на фотографијата Тим Гаув на Unsplash

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

Промена во размислувањето за потребата од метрика мора да се случи не само кај развивачите, туку и кај системските инженери.

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

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

Ова ја развива работата

Менталитетот devops ја опишува синергијата помеѓу развојното (dev) и оперативното (ops) размислување. Секоја компанија која тврди дека „прави devops“ мора:

1. кажувајќи работи што веројатно не ги прават (осврнувајќи се на мемето на Невестата на принцезата - „Мислам дека не значи тоа што вие мислите дека значи!“)
2. Охрабрете го ставот за постојано подобрување на производот.

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

Смени лево, ЛЕВО, РЕКОВ ЛИЕЕ-

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

Автор на фотографијата NESA од создавачи на Unsplash

Програмерите на софтвер мора да бидат способни да ги користат и да ги знаат алатките за следење што ги користи компанијата со цел да се изврши мониторинг во сите негови форми, метрика, евиденција, интерфејси за следење и што е најважно, гледајте како функционира нивниот производ во производството. Не можете да ги натерате програмерите да вложат труд и време во следењето сè додека не можат да ги видат метриките и да влијаат на тоа како изгледаат, како сопственикот на производот ги презентира на CTO на следниот брифинг итн.

На кратко

1. Водете го вашиот коњ до водата. Покажете им на програмерите колку неволји можат да избегнат за себе, помогни им да ги идентификуваат вистинските KPI и метрика за нивните апликации, така што ќе има помалку викање од сопственикот на производот на кој му вика CTO. Доведете ги на светлина, нежно и мирно. Ако тоа не функционира, тогаш подмитете, заканувајте се и закачете ги или нив или сопственикот на производот да ги имплементира добивањето на овие метрики од апликациите што е можно побрзо, а потоа нацртајте ги дијаграмите. Ова ќе биде тешко бидејќи нема да се гледа како приоритет, а патоказот на производот ќе има многу проекти што ќе генерираат приходи во очекување. Затоа, ќе ви треба деловен случај за да го оправдате времето и трошоците потрошени за спроведување на мониторинг на производот.
2. Помогнете им на системските инженери да имаат добар сон. Покажете им дека користењето на списокот за проверка „ајде да ослободиме“ за кој било производ што се издава е добра работа. И ако се осигурате дека сите апликации во производството се покриени со метрика, ќе ви помогне да спиете подобро ноќе со тоа што ќе им овозможите на програмерите да видат што и каде не е во ред. Сепак, вистинскиот начин да се иритира и фрустрира кој било развивач, сопственик на производ или CTO е да се истрае и да се спротивстави. Ваквото однесување ќе влијае на датумот на издавање на кој било производ ако повторно почекате до последната минута, па повторно префрлете се налево и внесете ги овие проблеми во вашиот проектен план што е можно поскоро. Доколку е потребно, појдете до состаноците за производи. Носете лажни мустаќи и филц или слично, никогаш нема да пропадне. Известете ги вашите грижи, покажете јасни придобивки и евангелизирајте.
3. Погрижете се и развојот (dev) и операциите (ops) да го разберат значењето и последицата на метриката на производот што се движи во црвената зона. Не оставајте го Ops како единствен чувар на здравјето на производите, проверете дали се вклучени и програмерите (#productsquads).
4. Дневниците се одлична работа, но исто така и метриката. Комбинирајте ги и не дозволувајте вашите трупци да станат ѓубре во огромна запалена топка на бескорисност. Објаснете и покажете им на програмерите зошто никој друг нема да ги разбере нивните дневници, покажете им како е да гледате бескорисни дневници во 3:15 часот наутро.

Автор на фотографијата Марко Хорват на Unsplash

Тоа е се. Новиот материјал ќе биде објавен следната недела. Доколку сакате да дознаете повеќе за курсот, ве покануваме Отворен ден, што ќе се одржи во понеделник. И сега традиционално ги чекаме вашите коментари.

Извор: www.habr.com