ru:https://highload.today/blogs/professii-devops-ne-sushhestvuet-programmistam-prosto-nuzhny-metriki-i-obratnaya-svyaz/ ua:https://highload.today/uk/blogs/professii-devops-ne-sushhestvuet-programmistam-prosto-nuzhny-metriki-i-obratnaya-svyaz/
logo
Мнение      17/06/2021

Профессии «девопс» не существует, программистам просто нужны метрики и обратная связь

Максим Лапшин BLOG

основатель Erlyvideo

Небольшой пост про то, что профессии «девопс» не существует, и про то, что программист должен чувствовать обратную связь от своей работы.

С оригинальным тредом можно ознакомиться в Twitter Максима Лапшина. Автор также советует прочесть небольшую заметку Ричарда Кука о том, как ломаются сложные системы: в ней врач в 1988 году описал всю сферу IT.

Как появились сисадмины-эксплуатационщики

Итак, программист что-то пишет и постоянно ломает, экспериментируя: за всем-то не уследишь головой. И чем полезнее система, тем глубже она описывает человеческие взаимодействия (которые все непостижимы, неописуемы и бесконечны). И вот, невозможно удержать все детали в голове.

Его работодатель при этом начинает потихоньку беситься: ведь все так хорошо начиналось, все было классно. А по прошествии года все стало медленно и постоянно ломаться. А потом начинается и возня с инфраструктурой: один сервер полетел, другой надо бекапить.

И тут возникает талантливая идея, решающая сразу две проблемы: давайте наймем кого-то подешевле, более склонного к удержанию порядка, чем к внесению хаоса. Поздравляю, мы изобрели сисадминов-эксплуатационщиков. Они берут софт у программиста, ставят на сервера и следят за этим.

Задача эксплуатационщика — снижать хаос, за это ему платят. Работодателю наконец стало приятно: вот он человек, который бережет его нервы. Ведь админ не только бекапит сервера, а еще и приструнил этого программиста, наладил график деплоев: март, август и октябрь. Тишь да гладь.

А потом выясняется, что внезапно развитие-то встало. Программист хреначит постоянно, ведь планы никто не отменял, штат раздут, людей в пять раз больше, но все превратилось в какой-то ад: то ничего не меняется, то марафоны апдейтов с седыми волосами и ночными починками.

Как программисты отказались отделены от пользователей

Но дальше больше. Начинается весь комплекс проблем и начинается он со слов «по ТЗ было так». В условиях, когда админ, борющийся с изменениями, стоит на пути изменений в продакшен, возникает Священное ТЗ. Этажи людей, строчащих ТЗ для того, чтобы побороть здравый смысл.

И что мы получили: люди, создающие что-то новое и в силу этого постоянно что-то ломающие, оказались отделены от пользователей теми, кто готов законсервировать все под таким слоем бюрократии, что даже вогоны содрогнулись бы. Графики релизов, релиз-менеджеры и прочая муть.

С такой организацией труда программисты начинают терять ощущение того, что там вообще с другой стороны живые люди. Выгорание, неприязнь к работе, непонимание, зачем вообще это все. С другой стороны, клиенты тоже страдают, ни один баг не может починиться.

Курс Project Manager від Powercode academy.
Онлайн-курс Project Manager. З нуля за 3,5 місяці до нової позиції Без знання коду, англійської та стресу.
Зарееструватися

Что с этим делать

Ясно, что нахрен вообще так жить. Надо что-то менять, но нельзя забывать с чего все началось. То есть нужна организация труда, которая не мешает программисту выкатывать код под клиентов, но не ломает весь продакшен. Как сохранить изменчивость компании, но не погрузиться в хаос?

Здесь рядом возникает еще другая ветка дискуссии: как вообще сохранять изменчивость, учитывая что время жизни требований зачастую сравнимо или меньше, чем время их имплементации. То есть, начиная писать код, мы точно знаем, что вот это мы не допишем, а допишем что-то другое.

Плюс к тому, что надо давать релизить в продакшен мимо админов, надо еще вернуть обратно программистам ощущение того, что они работают не ради чеклиста в ТЗ, а ради результата. Возникает целый пласт вопросов: а как его увидеть, если серверов уже не 1, а 1 000 и логи необозримы?

То есть:

  • пишем код в прод,
  • не тратим время на мелкую возню с продом,
  • не ломаем прод,
  • видим эффект изменений,
  • радуемся ощущению востребованности работы,
  • Онлайн-курс "Marketing Basis" від Skvot.
    Навчіться проводити аналіз конкурентів і цільової авдиторії, формувати місію та позиціювання. Розберіться з бюджетами і метриками, щоб обирати ефективні канали комунікації.Поєднайте цифри і креатив.
    Про курс
  • можем по итогу скорректировать планы.

Ну понятно, что мы тут говорим про agile и DevOps, причем без какого либо надрыва и истерики.

Для того, чтобы программист мог писать код в прод, надо чтобы кто-то, противостоящий хаосу, мог безболезненно откатить эти изменения. То есть откатываемость — очень важная характеристика. Поднес руку к паяльнику, убрал — плохо. Можно попробовать с другой стороны. Define «плохо».

Как понять, что код стал плохим

Чтобы понять, что код стал плохим, надо зайти немного дальше. Иногда достаточно просто констатации того, что количество эксепшенов выросло в два раза, в более взрослых проектах могут померять результаты продуктового мониторинга (об этом позже).

Но если начать мерять, то очень быстро можно понять, что на самом деле проблемы очень часто неплохо замеряются. А значит, можно доверить замеры скрипту, который примет решение: откатывать или оставлять. То есть мы научились хаос уменьшать. А как не погружаться в него?

А тут все очень просто: канареечный деплой — современная азбука. Чтобы не погружать в хаос весь проект, надо делать это маленькими шажками. Проверять все на антихрупкость. Ломать всю систему по чуть-чуть — полезно и нужно. Даже если хватает одного сервера, нужно завести три.

Выложили новый код на один из трех, померяли, что получается. Если стало не хуже, значит, можно дальше. И все, постоянно все надо регулярно по чуть-чуть ломать, проверяя устойчивость системы к настоящим поломкам. Chaos monkey, да. Спасение от хаоса лишь на границе хаоса. W40K!

Итого, мы вырастили скрипт, которому можно дать новый код, он его выложит на один сервер из списка, померяет градусником, выкатит дальше или откатит назад. Собственно, ровно так и возникает Kubernetes. Это инструмент программиста для раскатки кода.

Как же померять? Как понять, что код плохой или хороший? Здесь возникает профессия человека, который отвечает на вопросы: кому в этом проекте жить хорошо и от чего. Да-да, тот самый продакт с его метриками. На крупном проекте ошибки и 500-ки хлещут постоянно. Все на грани хаоса.

Онлайн-курс "Ілюстрація Basis" від Skvot.
Від софтів та основ ілюстрування — до перших клієнтів.Adobe Photoshop, Adobe Illustrator та Procreate.Дізнайтесь, як розвивати особистий бренд, знаходити клієнтів та гідно оцінювати свої роботи.
Про курс

Но все, что прогается, прогается ради клиентов, ради их удобства, чтобы они как можно больше сервиса получили. Собственно, если ошибок в sentry стало больше, а график уровня сервиса не поменялся, значит, эти ошибки диагностируются ошибочно, все ок на самом деле. Продуктовая метрика.

В отличие от примитивных штук типа «сколько RPS держим» или чего-то еще подобного, метрики — это предмет ежедневной рефлексии и переосмысления. Это часть того, как бизнес сам себя на рынке ощущает. То человеческое, неосязаемое, что пытаются выразить в программировании.

Почему для программиста важны метрики

Программисту надо видеть эти метрики, иначе он идет не вместе с бизнесом и клиентами, а куда-то в другую сторону. Частью работы должен быть анализ влияния изменений на эти метрики. Смотрите, как уже поменялся подход ко всей работе:

  • Я написал код по ТЗ, какие ко мне вопросы?
  • Я задеплоил код (тут мы пропустили этап внедрения тестов, но это как бы уже совсем примитивно).
  • Я убедился в том, что код не откатился.
  • Я убедился в том, что код не сделал хуже проекту.
  • Я увидел, как он сделал лучше.

Вот собственно где-то в конце этого уже и можно говорить о внедрении DevOps-подходов, потому что без них туда вообще не прийти. Чтобы не заниматься бессмысленной тряхомудией с настройкой Redis и откатом деб-пакетов, существует DevOps-машинерия. НО НЕ ДЕВОПСЕРЫ!

Онлайн-курс "Корпоративні фінанси" від Laba.
Дізнайтесь як рахувати unit-економіку та управляти фінансовими ризиками компанії.Навчіться будувати фінмодель та розраховувати інвестиційні показники й боргове навантаження.
Детальніше про курс

Все, о чем мы тут говорили, это про то, как поменять работу программистов, чтобы они перестали гробить бизнес своими косяками, но могли ежедневно вносить изменения. DevOps — это перестройка разработки с «девелоперы — эксплуатационщики» на «девелоперы + инструментарий».

Следствие всего этого: никому уже не нужны полуторалетние релиз-марафоны. Чтобы можно было обозреть изменения, увидеть их влияние, они должны быть небольшими, иначе слишком сильно их взаимное влияние друг на друга. Сделал немножко — задеплоил, проверил, померял.

То есть, внедряя скрипты для отката, мы пришли к обозримым и измеримым изменениям, которые можно сделать, только делая небольшие итерации, при наличии генерального плана. Вот вам и кусочек agile сам по себе. Еще раз рекомендую прочитать Ричарда Кука — просто азбука нашей профессии.

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Онлайн-курс "Ціноутворення для виробників та ритейлу" від Laba.
Масштабуйте бізнес, незалежно від конкурентів, завдяки оптимізації стратегії ціноутворення.Досвід та фідбек від Senior Product Manager Pricing Platform у Zalando.
Детальніше про курс

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.

Ваша жалоба отправлена модератору

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: