Один из главных источников боли — изменения и релизы. Новые фичи, конечно, радуют глаз. Но если из-за инцидентов вы не успеваете зарабатывать — рано или поздно за вами приедет бизнес с веником.
Но есть приём, который помогает держать баланс между разработкой и устойчивостью. Простая (очень!😳 ) штука — считать деньги.
Делать это идеально в применении к инцидентам, конечно, невозможно, но можно пытаться. Осознавая, что инциденты всё равно будут — закладывайте их в бюджет. Прямо в план.
На основании статистики — можно прикинуть, сколько денег система приносит в час, а после каждого инцидента прикинуть, сколько не досчитались.
Если случился инцидент — дело не только в том, чтобы пофиксить баг. Нужно "списать" полученный убыток из error budget-а и смотреть, не ушёл ли баланс в минус. Потому что если ушёл — значит пора остановиться и подумать: всё ли мы так делаем?
Может быть накопился техдолг? Может быть что-то не так в процессах? Может что-то не так в головах?
Пришло время латать дыры, а потом — можно будет снова приоткрыть краник восхитительных изменений, которые принесут миллиарды денег когда-нибудь потом.
Латать дыры в одиночку бесполезно — нужно собрать всех: инженеров, разработчиков, менеджмент, саппорт. Посмотреть, что ломалось, что уже давно бесит, что надо пофиксить в первую очередь, чтобы система снова начала держаться на ногах.
Потому что фичи подождать могут, а если по итогам месяца кончатся деньги — то и новые отличные идеи делать будет не на что.
Но есть приём, который помогает держать баланс между разработкой и устойчивостью. Простая (очень!
Делать это идеально в применении к инцидентам, конечно, невозможно, но можно пытаться. Осознавая, что инциденты всё равно будут — закладывайте их в бюджет. Прямо в план.
На основании статистики — можно прикинуть, сколько денег система приносит в час, а после каждого инцидента прикинуть, сколько не досчитались.
Если случился инцидент — дело не только в том, чтобы пофиксить баг. Нужно "списать" полученный убыток из error budget-а и смотреть, не ушёл ли баланс в минус. Потому что если ушёл — значит пора остановиться и подумать: всё ли мы так делаем?
Может быть накопился техдолг? Может быть что-то не так в процессах? Может что-то не так в головах?
Пришло время латать дыры, а потом — можно будет снова приоткрыть краник восхитительных изменений, которые принесут миллиарды денег когда-нибудь потом.
Латать дыры в одиночку бесполезно — нужно собрать всех: инженеров, разработчиков, менеджмент, саппорт. Посмотреть, что ломалось, что уже давно бесит, что надо пофиксить в первую очередь, чтобы система снова начала держаться на ногах.
Потому что фичи подождать могут, а если по итогам месяца кончатся деньги — то и новые отличные идеи делать будет не на что.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22👍3
Хватит умножать сроки проекта на π (потому что, ну, «п***ц же!»). Это не научно!
И вообще — π хорош только в кружках и татухах. В оценках — он вреден.
Если хотите реалистичную прикидку по срокам — умножайте на e.
Потому что рост неопределённости — экспоненциален, детка.
Теперь, давайте подушним?! Итак, почему π — фиговый множитель в управлении неопределённостью:
1. В искривлённом пространстве — π плавает. В геометрии Лобачевского, например, сумма углов треугольника уже не 180°, а π там вообще не тот. Ну и как вы собираетесь на этом считать дедлайны?
2. В пространствах с размерностью больше 3 всё ещё веселее: для расчёта объёмов и площадей вместо π всплывает π², πⁿ и прочие сущности, о которых вы точно не думали, когда прибавляли ещё месяц «на всякий».
3. На планковском уровне вообще всё теряет смысл. Там нет ни окружности, ни радиуса, ни уверенности. Оценки становятся вероятностными, и вся эта арифметика — чисто философский экспириенс.
Так что забудьте про π! Хотите работать с хаосом — думайте в терминах экспоненты. Она строго аналитическая, абсолютная и неизменная!
А ещё у экспоненты есть производная. И она равна самой себе. Ещё один повод для уважения!
И вообще — π хорош только в кружках и татухах. В оценках — он вреден.
Если хотите реалистичную прикидку по срокам — умножайте на e.
Потому что рост неопределённости — экспоненциален, детка.
Теперь, давайте подушним?! Итак, почему π — фиговый множитель в управлении неопределённостью:
2. В пространствах с размерностью больше 3 всё ещё веселее: для расчёта объёмов и площадей вместо π всплывает π², πⁿ и прочие сущности, о которых вы точно не думали, когда прибавляли ещё месяц «на всякий».
3. На планковском уровне вообще всё теряет смысл. Там нет ни окружности, ни радиуса, ни уверенности. Оценки становятся вероятностными, и вся эта арифметика — чисто философский экспириенс.
Так что забудьте про π! Хотите работать с хаосом — думайте в терминах экспоненты. Она строго аналитическая, абсолютная и неизменная!
А ещё у экспоненты есть производная. И она равна самой себе. Ещё один повод для уважения!
🤣33🔥16
Как-то раз наблюдал мастер-класс под названием "Принятие решений в условиях неопределённости, которую мы сами же и создали".
Полчаса обсуждали варианты, опасения, рассуждали, кто бы мог этим заняться… вместо того, чтобы остановиться на том, что есть нехватка информации и надо выяснить, как оно устроено. В какой-то момент я вдруг осознал, что я умею не только ртом шевелить, залез в кластер – и, о чудо, нашёл ответ за две минуты. С полученным ответом решение стало очевидно без рассуждений.
Говорить и покручивать ситуацию с разных сторон – норм. Но если можно добыть информацию за пару кликов, или добыть того, кто добудет нужные ответы, но вместо этого устраивать круглый стол на полчаса – это уже трындец.
Не надо так.
Принимайте решения “на месте”, а не в облаках.
Полчаса обсуждали варианты, опасения, рассуждали, кто бы мог этим заняться… вместо того, чтобы остановиться на том, что есть нехватка информации и надо выяснить, как оно устроено. В какой-то момент я вдруг осознал, что я умею не только ртом шевелить, залез в кластер – и, о чудо, нашёл ответ за две минуты. С полученным ответом решение стало очевидно без рассуждений.
Говорить и покручивать ситуацию с разных сторон – норм. Но если можно добыть информацию за пару кликов, или добыть того, кто добудет нужные ответы, но вместо этого устраивать круглый стол на полчаса – это уже трындец.
Не надо так.
Принимайте решения “на месте”, а не в облаках.
👍22🤯4
👀 А код-ревью — вообще нужен для качества?
Мне иногда кажется, что вокруг код-ревью построен культ. Тимлиды часами обсуждают, как "оптимально распределять ревьювера", как "улучшить процесс", как это якобы "повышает качество продукта". Но у меня с этим опытом — по-другому.
ИМХО, код-ревью отлично работает, когда речь идёт о:
- переопылении неочевидных знаний о системе,
- менторстве и росте джунов,
- командной синхронизации.
Но как quality gate — это слабый инструмент. Он не гарантирует, что баг не пройдёт. Не страхует от архитектурной кривизны. И откровенно тормозит delivery.
Особенно в сложных фичах: чтобы оценить PR по-настоящему, нужно столько контекста, что проще сесть рядом и в паре закодить.
Если цель — ловить критические ошибки, можно же:
- сделать линтеры и написать автотесты,
- сделать чек-листы и кейсы для тестирования и самопроверки,
- уменьшить зоны неопределённости в коде
А код-ревью пусть остаётся тем, что у него получается лучше всего — развитием команды.
Может не надо натягивать его на задачи, к которым он плохо приспособлен?
Или я чего-то не вижу?
Поговорите со мной в комментах, мне очень кажется, что я что-то упускаю, а для всех это очевидно.
Мне иногда кажется, что вокруг код-ревью построен культ. Тимлиды часами обсуждают, как "оптимально распределять ревьювера", как "улучшить процесс", как это якобы "повышает качество продукта". Но у меня с этим опытом — по-другому.
ИМХО, код-ревью отлично работает, когда речь идёт о:
- переопылении неочевидных знаний о системе,
- менторстве и росте джунов,
- командной синхронизации.
Но как quality gate — это слабый инструмент. Он не гарантирует, что баг не пройдёт. Не страхует от архитектурной кривизны. И откровенно тормозит delivery.
Особенно в сложных фичах: чтобы оценить PR по-настоящему, нужно столько контекста, что проще сесть рядом и в паре закодить.
Если цель — ловить критические ошибки, можно же:
- сделать линтеры и написать автотесты,
- сделать чек-листы и кейсы для тестирования и самопроверки,
- уменьшить зоны неопределённости в коде
А код-ревью пусть остаётся тем, что у него получается лучше всего — развитием команды.
Может не надо натягивать его на задачи, к которым он плохо приспособлен?
Или я чего-то не вижу?
Поговорите со мной в комментах, мне очень кажется, что я что-то упускаю, а для всех это очевидно.
👍25💩2
Forwarded from Knowledge and bacon - Управление знаниями в IT
Дарья Мулык Как грамотно общаться с экспертами, от которых вам нужны знания.
Даша рассказала про подход к распаковке знаний экспертов, который можно применять как для создания баз знаний и документации, так и внутренних курсов, онбординг планов, технических статей: от как продать идею эксперту до как вовлечь других людей в компании.
Вот его составляющие:
- Подчеркните его экспертность
- Покажите, что вы тоже эксперт, но в упаковке/методологии/текстах/обучении
- Покажите, в чем ценность для эксперта / как это сделает его жизнь проще
- Сделайте процесс удобным, обложите его темплейтами, готовыми вопросами для старта и тд
- Покажите, как другие выигрывают от этого
- Оцените готовность
Можете брать готовый чек-лист вопросов для брифа эксперта и адаптировать под себя.
#KnowledgeConf
Даша рассказала про подход к распаковке знаний экспертов, который можно применять как для создания баз знаний и документации, так и внутренних курсов, онбординг планов, технических статей: от как продать идею эксперту до как вовлечь других людей в компании.
Вот его составляющие:
- Подчеркните его экспертность
- Покажите, что вы тоже эксперт, но в упаковке/методологии/текстах/обучении
- Покажите, в чем ценность для эксперта / как это сделает его жизнь проще
- Сделайте процесс удобным, обложите его темплейтами, готовыми вопросами для старта и тд
- Покажите, как другие выигрывают от этого
- Оцените готовность
Можете брать готовый чек-лист вопросов для брифа эксперта и адаптировать под себя.
#KnowledgeConf
👍6💩5
Когда Agile — это не про гибкость, а про хоть какую-то опору
Вы тоже немного устали от того, как насильно пытаются внедрить Scrum и Agile куда ни попадя? Особенно когда, кажется, это делается просто чтобы "как у всех".
Но вот интересный инсайт у меня случился. Сейчас я учусь на курсе "Руководитель отдела" в Стратоплане — и начинает вырисовываться новый уровень понимания того, как работает компания в целом.
Давайте представим: вы — CТО в крупной компании. Не стартап из пятерых человек, а такая развесистая структура, тысячи людей, несколько бизнес-доменов, десятки команд в каждом.
Приходите вы туда — и видите:
— задачи ставятся кто во что горазд
— планирование везде устроено по-разному
— какие-то “проекты”, где-то "инициативы", где-то просто список задач
— поводы у заведению задач у всех тоже разные — кто-то поквартально работает, кто-то в режиме "фигачь и будь что будет"
— трекинг как получится,
— дай бог 20% выполнения обязательств, взятых на себя
И вам прилетает сверху, от борда директоров: "у вас тут плохо всё с выполнением задач, стратегические цели не выполняются, исправь".
И вы такие: а где тут в этом "плохо" — то самое "всё"? Где границы, где процессы, где точка отсчёта?
Систему, где нет общей рамки, невозможно починить точечно. Формирование одного "проектного офиса" не спасёт. Нужно что-то большее, Идея, которая всех направит хотя бы в одну сторону. И желательно ещё — Идея такая, чтобы её не надо было долго объяснять, чтобы хотя бы что-то про неё уже слышали.
И вот тут Agile и Scrum, какими бы словами их не хотелось назвать — внезапно становятся полезны! Потому что они дают общий язык, потому что они дают возможность нанять людей, которые хоть где-то наводили порядок с морем команд. Пусть не идеально, пусть отчасти формально — но хоть как-то!
А внутри системы, где все заняты выживанием и сохранением статус кво, редко кто способен организовать изменения сам. Нужно внешнее усилие: консультанты, обучение, давление руководства "сверху".
Когда выполнение целей компании колеблется где-то между 0 и 20%, выбирать не из чего. Нужно поднимать этот процент, и для этого приходится искать любые зацепки, чтобы согласовать людей между собой.
Agile — это конечно не решение, но это перила, которые нужны этой лестнице. А идти по ней, конечно, придётся всей компании.
Вы тоже немного устали от того, как насильно пытаются внедрить Scrum и Agile куда ни попадя? Особенно когда, кажется, это делается просто чтобы "как у всех".
Но вот интересный инсайт у меня случился. Сейчас я учусь на курсе "Руководитель отдела" в Стратоплане — и начинает вырисовываться новый уровень понимания того, как работает компания в целом.
Давайте представим: вы — CТО в крупной компании. Не стартап из пятерых человек, а такая развесистая структура, тысячи людей, несколько бизнес-доменов, десятки команд в каждом.
Приходите вы туда — и видите:
— задачи ставятся кто во что горазд
— планирование везде устроено по-разному
— какие-то “проекты”, где-то "инициативы", где-то просто список задач
— поводы у заведению задач у всех тоже разные — кто-то поквартально работает, кто-то в режиме "фигачь и будь что будет"
— трекинг как получится,
— дай бог 20% выполнения обязательств, взятых на себя
И вам прилетает сверху, от борда директоров: "у вас тут плохо всё с выполнением задач, стратегические цели не выполняются, исправь".
И вы такие: а где тут в этом "плохо" — то самое "всё"? Где границы, где процессы, где точка отсчёта?
Систему, где нет общей рамки, невозможно починить точечно. Формирование одного "проектного офиса" не спасёт. Нужно что-то большее, Идея, которая всех направит хотя бы в одну сторону. И желательно ещё — Идея такая, чтобы её не надо было долго объяснять, чтобы хотя бы что-то про неё уже слышали.
И вот тут Agile и Scrum, какими бы словами их не хотелось назвать — внезапно становятся полезны! Потому что они дают общий язык, потому что они дают возможность нанять людей, которые хоть где-то наводили порядок с морем команд. Пусть не идеально, пусть отчасти формально — но хоть как-то!
А внутри системы, где все заняты выживанием и сохранением статус кво, редко кто способен организовать изменения сам. Нужно внешнее усилие: консультанты, обучение, давление руководства "сверху".
Когда выполнение целей компании колеблется где-то между 0 и 20%, выбирать не из чего. Нужно поднимать этот процент, и для этого приходится искать любые зацепки, чтобы согласовать людей между собой.
Agile — это конечно не решение, но это перила, которые нужны этой лестнице. А идти по ней, конечно, придётся всей компании.
👍21🔥7🤔5💩1🤣1
Куда вы деваете людей из своей головы?
Вот вы с кем-то поговорили на конференции/по работе, вроде интересный человек. Полезный, важный, смешной, талантливый. Что дальше?
- Кто-то сохраняет такие контакты в телефоне — и пишет туда кучу заметок.
- Кто-то — кидает себе в "Избранное" в Телеге, чтобы не забыть.
- Кто-то ведёт отдельную таблицу с пометками вроде “Максим — делает мебель" / "Пётр — javascript" / "Василий — devops", "Кристина — Яндекс"
А кто-то — вообще ничего не делает, полагается на мозг. (Удачи, лол!)
А есть такие, кто реально строит свою сеть контактов — не из тщеславия, а потому что люди = возможности. Особенно это актуально становится, когда надо найти работу, собрать команду, запустить проект или найти ответы из реальной практики.
Я заморочился и сделал бота, который помогает это делать почти без усилий — форварднул сообщение от человека => бот обработал его и положил в базу знаний.
Но вот в чём вопрос.
А вы вообще как? Храните контакты, ведёте базу? Или это всё слишком?
Вот вы с кем-то поговорили на конференции/по работе, вроде интересный человек. Полезный, важный, смешной, талантливый. Что дальше?
- Кто-то сохраняет такие контакты в телефоне — и пишет туда кучу заметок.
- Кто-то — кидает себе в "Избранное" в Телеге, чтобы не забыть.
- Кто-то ведёт отдельную таблицу с пометками вроде “Максим — делает мебель" / "Пётр — javascript" / "Василий — devops", "Кристина — Яндекс"
А кто-то — вообще ничего не делает, полагается на мозг. (Удачи, лол!)
А есть такие, кто реально строит свою сеть контактов — не из тщеславия, а потому что люди = возможности. Особенно это актуально становится, когда надо найти работу, собрать команду, запустить проект или найти ответы из реальной практики.
Я заморочился и сделал бота, который помогает это делать почти без усилий — форварднул сообщение от человека => бот обработал его и положил в базу знаний.
Но вот в чём вопрос.
А вы вообще как? Храните контакты, ведёте базу? Или это всё слишком?
🤯10👍3🤔1
Как ты сейчас работаешь с полезными контактами?
Final Results
13%
Держу в голове, авось вспомню
25%
Пишу заметки в телефонных контактах
18%
Сохраняю в избранное/чаты в Телеге
8%
Веду таблицу / базу / Notion
2%
Делаю записи на бумаге
33%
Ничего не делаю, не надо заморачиваться!
3%
🤓 У меня есть своя система (напишу в комменты)
Когда "управление ожиданиями" — это не про честный диалог, а про угадайку
Продолжаю делиться своими инсайтами с курса "руководитель отдела", про то, что греет и бесит одновременно.
Есть такой миф, что управление ожиданиями — это про зрелый разговор двух взрослых людей, мол: "давай обсудим, чего ты хочешь, а что реально, и найдем середину". Но что делать, если один из этих "взрослых" — твой руководитель, который не особо настроен на разговор?
Что делать, если он уже всё придумал? Ему некогда. Он занят "стратегией". А тебе, подчинённому, — удачи в угадайке, как с этим жить!
Спойлер:ты всё равно отвечаешь за эту угадайку. Потому что управление ожиданиями — это всегда задача снизу вверх. Не хочешь — не справишься. Ушёл в обиду — остался в стороне. А в стороне быть не получится — ведь ты в операционке, а значит тебя закрутит по-полной!
И вот тут важно понимать: никакая аргументация "на словах" не пробьёт глухую стену.
Что нужно? Фактура. Прецеденты. Цифры.
Хочешь донести, что начальник выдумал фигню? Приноси доказательства. Не эмоциональные "мы так не вывозим", а "смотри, вот три примера, где мы так делали — и не сработало". И — "а вот тут сделали по-другому — и получилось".
Это не пассивная агрессия. Это конструктивная конфронтация.
Это не бунт. Это одна из важных функций менеджеров как таковых.
И ещё — учитывайте психотип. Кто-то воспринимает через истории, кто-то — через таблички, кто-то вообще не воспринимает, пока на цифрах не покажешь убыток. Не тратьте энергию на стену. Ищите подход. Снова и снова. Это и есть ваша работа.
Потому что если ты хочешь, чтобы наверху услышали, — сначала найди, как туда вообще достучаться.
Продолжаю делиться своими инсайтами с курса "руководитель отдела", про то, что греет и бесит одновременно.
Есть такой миф, что управление ожиданиями — это про зрелый разговор двух взрослых людей, мол: "давай обсудим, чего ты хочешь, а что реально, и найдем середину". Но что делать, если один из этих "взрослых" — твой руководитель, который не особо настроен на разговор?
Что делать, если он уже всё придумал? Ему некогда. Он занят "стратегией". А тебе, подчинённому, — удачи в угадайке, как с этим жить!
Спойлер:
И вот тут важно понимать: никакая аргументация "на словах" не пробьёт глухую стену.
Что нужно? Фактура. Прецеденты. Цифры.
Хочешь донести, что начальник выдумал фигню? Приноси доказательства. Не эмоциональные "мы так не вывозим", а "смотри, вот три примера, где мы так делали — и не сработало". И — "а вот тут сделали по-другому — и получилось".
Это не пассивная агрессия. Это конструктивная конфронтация.
Это не бунт. Это одна из важных функций менеджеров как таковых.
И ещё — учитывайте психотип. Кто-то воспринимает через истории, кто-то — через таблички, кто-то вообще не воспринимает, пока на цифрах не покажешь убыток. Не тратьте энергию на стену. Ищите подход. Снова и снова. Это и есть ваша работа.
Потому что если ты хочешь, чтобы наверху услышали, — сначала найди, как туда вообще достучаться.
👍49🔥5🤯1
Что для вас САМОЕ ценное в этом канале?
Final Results
25%
тут формулируют то, что накипело
22%
тут бывают отличные шутки
33%
тут бывают идеи, которыми хочется поделиться и пользоваться
23%
возможность понять, что у менеджеров в голове
22%
хочу быть среди прагматичных и немного циничных людей
31%
то, что не у одного меня такой п**ц
35%
ценен авторский способ мыслить и рассуждать
19%
я тебя знаю 😁
11%
максимальная концентрация полезного среди кучи шума
2%
другое в комменты
Я продолжаю обдумывать перспективы развития канала и новые проекты. Помогите, пожалуйста, проголосуйте и, по возможности, накидайте мыслей в комменты в посте выше.
Спасибо!
Спасибо!
🔥2
"Эти работы нельзя оценить!"
Ой, правда, что ли?
Любимый рефрен девопсов (да и не только их) — работы сложные, там всё непредсказуемо, надо влезать, разбираться, и, может быть, когда-нибудь потом они что-то скажут (нет, скажут "мы выкатили", когда уже всё сделали).
Особенно умиляет, когда это заявляет lead-devops-$500k-nanosec. И вот почему.
Оценка интеллектуального труда — штука с чудовищной погрешностью. Крайнее её проявление — нормочасы на перекладку JSON-ов и заполнение форм в Битриксе (хотя насчёт Битрикса я не уверен).
Как заказчик, я понимаю, что точных оценок быть не может. И у меня есть способы заложить риски, подстелить соломку, обеспечить проекту движение. Но мне нужно хоть что-то, с чем можно работать. Если инженерная команда вообще ничего не делает для прозрачности — это тупик.
Да, бывают незрелые команды, утерянная экспертиза, новые технологии, где даже простая задача может превратиться в ад на недели. Но именно поэтому упражнения по оценке и планированию нужны:
- Они помогают команде научиться формулировать мысли.
- Запускают внутри обмен экспертизой (а почему вот так, а не эдак?).
- Позволяют разобраться в неизвестной технологии или продукте.
- Заставляют рефлексировать и улучшать процессы.
И если lead-ml-dev-sec-llm-ops-$500k-nanosec этого не понимает — он просто создаёт себе уютное болотце. Вместо того чтобы разгружать себя через нормальные процессы, вводить стадию анализа и оценки, учить команду анализировать и формулировать — он увеличивает свою незаменимость и делает хуже всем.
Так что давайте без этих "нельзя оценить". Можно. И нужно.
Ой, правда, что ли?
Любимый рефрен девопсов (да и не только их) — работы сложные, там всё непредсказуемо, надо влезать, разбираться, и, может быть, когда-нибудь потом они что-то скажут (нет, скажут "мы выкатили", когда уже всё сделали).
Особенно умиляет, когда это заявляет lead-devops-$500k-nanosec. И вот почему.
Оценка интеллектуального труда — штука с чудовищной погрешностью. Крайнее её проявление — нормочасы на перекладку JSON-ов и заполнение форм в Битриксе (хотя насчёт Битрикса я не уверен).
Как заказчик, я понимаю, что точных оценок быть не может. И у меня есть способы заложить риски, подстелить соломку, обеспечить проекту движение. Но мне нужно хоть что-то, с чем можно работать. Если инженерная команда вообще ничего не делает для прозрачности — это тупик.
Да, бывают незрелые команды, утерянная экспертиза, новые технологии, где даже простая задача может превратиться в ад на недели. Но именно поэтому упражнения по оценке и планированию нужны:
- Они помогают команде научиться формулировать мысли.
- Запускают внутри обмен экспертизой (а почему вот так, а не эдак?).
- Позволяют разобраться в неизвестной технологии или продукте.
- Заставляют рефлексировать и улучшать процессы.
И если lead-ml-dev-sec-llm-ops-$500k-nanosec этого не понимает — он просто создаёт себе уютное болотце. Вместо того чтобы разгружать себя через нормальные процессы, вводить стадию анализа и оценки, учить команду анализировать и формулировать — он увеличивает свою незаменимость и делает хуже всем.
Так что давайте без этих "нельзя оценить". Можно. И нужно.
CI/CD для ленивых: самая база, как сделать так, чтобы всё само разворачивалось и не падало
Казалось бы, 2025 год, а CI/CD до сих пор есть не везде, где релизы — регулярная рутина. А там, где есть, оно порой работает так, что лучше бы не работало.
🤔 Для начала разберёмся с терминами
Есть путаница. CD — это не просто “нажал кнопку — код задеплоился”. Это подход к разработке, в котором каждое изменение потенциально готово к релизу (см. Фаулера — он пишет сложно, но полезно).
Но когда говорят “CI/CD”, чаще всего имеют в виду: “я запушил код, и он магически оказался на серверах”. Ну, магия магией, но работать это должно стабильно.
🤔 Как это устроено
Есть две модели доставки кода:
- Push — код выталкивается в среду (Jenkins, GitLab CI).
- Pull — среда сама забирает нужное из репозитория (ArgoCD, Flux).
Если триггернуться на слово "ArgoCD" — можно развести холивар про gitops-подходы, в этой заметке хотелось бы этого избежать. Поэтому сосредоточимся на GitLab CI — удобной системе, где CI/CD строится на простых скриптах.
Pipeline в GitLab CI — это просто последовательность команд. Например:
Этот pipeline обновляет код и перезапускает сервис. Всё просто? Нет.
🤔 Проблема с git pull
Наивная схема с git pull кажется рабочей, но тут две проблемы:
1. Изменения не атомарные!
Когда идёт git pull — файлы подменяются прямо на работающем сервисе. Если код обновился не весь (например, разорвался посреди обновления), приложение скорее всего разнесёт на куски.
2. Неуправляемое состояние.
Файлы на сервере могли быть случайно (или не случайно) изменёны вручную. Где гарантия, что git pull не выдаст конфликт? А если обновление потребует миграции БД?
Не получится сделать просто git pull && restart. Должен быть механизм откатов, контроль за зависимостями, тестирование перед выкладкой.
Ой, что-то сложно, давайте не делать? Можно сделать сначала "наивный" вариант, а по мере того, как будет отстреливать и придётся решать конфликты руками — обкладываться костылями вокруг. Эволюционный подход.
Ну или – сделать доставку атомарной сразу. Например, с помощью Docker?
🤔 Почему Docker не спасает
Окей, допустим, вместо git pull мы собираем и выкатываем контейнеры:
Но тут свои нюансы, которые иногда могут отстрелить нам ноги:
- Сборка образа не случится мгновенно. Если тянуть зависимости, сборка может идти долго.
- Чистка старых образов. Хранилище контейнеров растёт в размере, и если не следить, место на диске тупо кончится.
- Проблема зависимостей. Если код требует новую версию PostgreSQL, просто пересборка образа не поможет.
То есть Docker решает часть проблем, но не все (и создаёт новые😳 )
🤔 Почему у вас до сих пор нет CI/CD
1. Возможно вы не знаете bash? Не беда, у вас есть ChatGPT. Например, спросите его, как написать скрипт, который проверяет, запущен ли сервис, и если нет — перезапускает.
2. Возможно у вас нет времени? CI/CD как раз освобождает время. Задумайтесь, сколько часов в неделю уходит на ручные сборки, регрессы, конфликты при мерже. Выявите это и автоматизируйте.
3. Вас кидает с проекта на проект? Если нет времени на наведение порядка, может, пора сменить работу?
🤔 С чего начать
Начните с простого — автоматизируйте любую рутинную задачу. Например, вместо ручного git pull && restart сделайте скрипт:
И хотя бы проверьте, что он сработает, а не развалит всё к чертям.
CI/CD — это не про сложные пайплайны, а про здравый смысл. Чем раньше начнёте, тем меньше будете тратить время на рутину.
Казалось бы, 2025 год, а CI/CD до сих пор есть не везде, где релизы — регулярная рутина. А там, где есть, оно порой работает так, что лучше бы не работало.
Есть путаница. CD — это не просто “нажал кнопку — код задеплоился”. Это подход к разработке, в котором каждое изменение потенциально готово к релизу (см. Фаулера — он пишет сложно, но полезно).
Но когда говорят “CI/CD”, чаще всего имеют в виду: “я запушил код, и он магически оказался на серверах”. Ну, магия магией, но работать это должно стабильно.
Есть две модели доставки кода:
- Push — код выталкивается в среду (Jenkins, GitLab CI).
- Pull — среда сама забирает нужное из репозитория (ArgoCD, Flux).
Если триггернуться на слово "ArgoCD" — можно развести холивар про gitops-подходы, в этой заметке хотелось бы этого избежать. Поэтому сосредоточимся на GitLab CI — удобной системе, где CI/CD строится на простых скриптах.
Pipeline в GitLab CI — это просто последовательность команд. Например:
stages:
- update_code
- restart_service
update_code:
stage: update_code
script:
- git pull origin main
restart_service:
stage: restart_service
script:
- systemctl restart myservice
Этот pipeline обновляет код и перезапускает сервис. Всё просто? Нет.
Наивная схема с git pull кажется рабочей, но тут две проблемы:
1. Изменения не атомарные!
Когда идёт git pull — файлы подменяются прямо на работающем сервисе. Если код обновился не весь (например, разорвался посреди обновления), приложение скорее всего разнесёт на куски.
2. Неуправляемое состояние.
Файлы на сервере могли быть случайно (или не случайно) изменёны вручную. Где гарантия, что git pull не выдаст конфликт? А если обновление потребует миграции БД?
Не получится сделать просто git pull && restart. Должен быть механизм откатов, контроль за зависимостями, тестирование перед выкладкой.
Ой, что-то сложно, давайте не делать? Можно сделать сначала "наивный" вариант, а по мере того, как будет отстреливать и придётся решать конфликты руками — обкладываться костылями вокруг. Эволюционный подход.
Ну или – сделать доставку атомарной сразу. Например, с помощью Docker?
Окей, допустим, вместо git pull мы собираем и выкатываем контейнеры:
script:
- docker build -t my-app .
- docker run -d my-app
Но тут свои нюансы, которые иногда могут отстрелить нам ноги:
- Сборка образа не случится мгновенно. Если тянуть зависимости, сборка может идти долго.
- Чистка старых образов. Хранилище контейнеров растёт в размере, и если не следить, место на диске тупо кончится.
- Проблема зависимостей. Если код требует новую версию PostgreSQL, просто пересборка образа не поможет.
То есть Docker решает часть проблем, но не все (и создаёт новые
1. Возможно вы не знаете bash? Не беда, у вас есть ChatGPT. Например, спросите его, как написать скрипт, который проверяет, запущен ли сервис, и если нет — перезапускает.
2. Возможно у вас нет времени? CI/CD как раз освобождает время. Задумайтесь, сколько часов в неделю уходит на ручные сборки, регрессы, конфликты при мерже. Выявите это и автоматизируйте.
3. Вас кидает с проекта на проект? Если нет времени на наведение порядка, может, пора сменить работу?
Начните с простого — автоматизируйте любую рутинную задачу. Например, вместо ручного git pull && restart сделайте скрипт:
#!/bin/bash
git pull origin main && systemctl restart myservice
И хотя бы проверьте, что он сработает, а не развалит всё к чертям.
CI/CD — это не про сложные пайплайны, а про здравый смысл. Чем раньше начнёте, тем меньше будете тратить время на рутину.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19🤣6
Некоторые люди, кажется, рождаются с убеждением, что они альфа, омега и вообще мерило всего сущего. Особенно ярко это проявляется на рабочих обсуждениях. Стоит предложить альтернативный подход, как тут же слышишь: "Так это не работает!" или "Давай доказательства, где это так?".
Такая жесткая модерация может быстро погасить инициативу и вовлечённость в команде. Вокруг "лидера" останутся лишь те, кто безропотно соглашается, и готов убить свою мысль под давлением авторитета.
Почему это происходит? Несмотря на декларируемую цель "достичь результата", невербальный мотив такого человека звучит как "главный тут я". А когда кому-то позарез надо быть главным, общение превращается в тупиковый спор: заноза в заднице мешает адекватно воспринимать других.
Что делать, если вы столкнулись с таким "лидером"?
1. Берите ответственность на себя. Вместо расплывчатого "можно попробовать сделать так" говорите чётко: "Я сделаю это к такому-то сроку". Это вызовет агрессию, риски высоки, но это единственный путь сохранить свою позицию.
2. Валите к чертям. Если человек системно отравляет команду, а исправить его поведение невозможно, лучше уйти. Жизнь слишком коротка, чтобы работать с мудаками.
И помните: быть главным — это не безусловное доминирование, а умение слушать и вдохновлять.
Такая жесткая модерация может быстро погасить инициативу и вовлечённость в команде. Вокруг "лидера" останутся лишь те, кто безропотно соглашается, и готов убить свою мысль под давлением авторитета.
Почему это происходит? Несмотря на декларируемую цель "достичь результата", невербальный мотив такого человека звучит как "главный тут я". А когда кому-то позарез надо быть главным, общение превращается в тупиковый спор: заноза в заднице мешает адекватно воспринимать других.
Что делать, если вы столкнулись с таким "лидером"?
1. Берите ответственность на себя. Вместо расплывчатого "можно попробовать сделать так" говорите чётко: "Я сделаю это к такому-то сроку". Это вызовет агрессию, риски высоки, но это единственный путь сохранить свою позицию.
2. Валите к чертям. Если человек системно отравляет команду, а исправить его поведение невозможно, лучше уйти. Жизнь слишком коротка, чтобы работать с мудаками.
И помните: быть главным — это не безусловное доминирование, а умение слушать и вдохновлять.
👍28💩2🤔1
Если вы тоже пользуетесь Obsidian - присмотритесь к новой фиче, которая пока что доступна в альфа-режиме
https://obsidian.md/changelog/2025-05-21-desktop-v1.9.0/
Они завозят базы как в Notion!
https://obsidian.md/changelog/2025-05-21-desktop-v1.9.0/
Они завозят базы как в Notion!
Obsidian
Obsidian 1.9.0 Desktop (Early access)
Introducing [Bases](https://help.obsidian.md/bases), a new core plugin that lets you turn any set of notes into a powerful database. With Bases you can organize...
🔥13🎉4👍2
По мотивам своего восхитительного рассказана на devopsconf Виктор Корейша опубликовал статью.
Как сделать нормальную авторизацию в Kafka, когда у тебя огромный трафик и высочайший уровень ответственности:
https://habr.com/ru/companies/ozontech/articles/921642/
Как сделать нормальную авторизацию в Kafka, когда у тебя огромный трафик и высочайший уровень ответственности:
https://habr.com/ru/companies/ozontech/articles/921642/
Хабр
Авторизация в Kafka: управление изменениями, когда у тебя тысячи клиентов и миллионы RPS
У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырёх языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жёсткие...
🔥5
Вот вы говорите: bus factor — это плохо.
И я соглашусь. Но не просто потому что «уйдёт ключевой человек и всё рухнет». Проблема глубже.
Незаменимость убивает возможность устанавливать общие правила: что такое хорошо, а что плохо.
Почему? Да потому что когда у тебя в команде есть уникальный спец, которого невозможно потерять — ты не можешь его наказать даже за откровенное дерьмо.
Так появляется каста «брахманов», на которых не распространяются правила.
— Кричать на коллегу? Нельзя.
— Но он же наш гений.
— Ну ему можно
— Нарушать процессы? Нет, они писаны кровью
— Но это же Вася, без него никто в этом не разберётся, что ты с ним сделаешь
В итоге в компании формируется извращённая этика. Для всех остальных — "работаем по правилам, уважаем друг друга". Для священных коров — "делай что хочешь, лишь бы не уволился".
Это не просто раздражает. Это разлагает. В команде постепенно стирается понимание "что такое хорошо" и "что такое плохо". Невозможно требовать качества и ответственности, когда нет единых стандартов для всех. Люди фрустрируются. Перестаёт быть понятно, ради чего вообще стоит стараться. Про продуктивность говорить бессмысленно — ты не можешь синхронизировать усилия команды, если у тебя внутри эта феодальная вольница.
Новые сотрудники быстро научатся: тут главное не правила соблюдать, а стать незаменимым. Начинают прятать знания, избегать документации, саботировать онбординг новичков. Потому что так тут принято выживать и это работает.
Bus factor — это не только риск внезапного увольнения. Это ещё и медленный яд для всей культуры и продуктивности в целом.
И я соглашусь. Но не просто потому что «уйдёт ключевой человек и всё рухнет». Проблема глубже.
Незаменимость убивает возможность устанавливать общие правила: что такое хорошо, а что плохо.
Почему? Да потому что когда у тебя в команде есть уникальный спец, которого невозможно потерять — ты не можешь его наказать даже за откровенное дерьмо.
Так появляется каста «брахманов», на которых не распространяются правила.
— Кричать на коллегу? Нельзя.
— Но он же наш гений.
— Ну ему можно
— Нарушать процессы? Нет, они писаны кровью
— Но это же Вася, без него никто в этом не разберётся, что ты с ним сделаешь
В итоге в компании формируется извращённая этика. Для всех остальных — "работаем по правилам, уважаем друг друга". Для священных коров — "делай что хочешь, лишь бы не уволился".
Это не просто раздражает. Это разлагает. В команде постепенно стирается понимание "что такое хорошо" и "что такое плохо". Невозможно требовать качества и ответственности, когда нет единых стандартов для всех. Люди фрустрируются. Перестаёт быть понятно, ради чего вообще стоит стараться. Про продуктивность говорить бессмысленно — ты не можешь синхронизировать усилия команды, если у тебя внутри эта феодальная вольница.
Новые сотрудники быстро научатся: тут главное не правила соблюдать, а стать незаменимым. Начинают прятать знания, избегать документации, саботировать онбординг новичков. Потому что так тут принято выживать и это работает.
Bus factor — это не только риск внезапного увольнения. Это ещё и медленный яд для всей культуры и продуктивности в целом.
👍41🔥11
Как-то один замечательный человек спросил:
Хороший вопрос. Но давайте сразу разберёмся — а мы про что именно?
Есть два совершенно разных уровня:
👉 1. Технические SLA 👈
Это твоя зона ответственности. Здесь всё предельно скучно и конкретно:
- гарантия сохранности и доставки сообщений (с кучей сносок и оговорок)
- работоспособность коннекторов и интеграций (Debezium и прочие)
- живые алерты и мониторинг (если упало — узнали)
- что интерфейсы мониторинга реально что-то показывают
- что есть возможность внести изменения в конфиги без плясок с бубном
Тут надо оговориться, что сохранность сообщений это сложная тема. Ты не можешь отвечать за приёмку чужих данных полностью — максимум за то, что, получив, запишешь их надёжно и сколько-то подержишь. Почему-то не очевидно, что “пуля вылетела со стороны моего приложения” — ещё не значит, что она долетела до хранилища. И обязательно надо формализовть: срок хранения, объём, всяческие оговорки вроде что происходит если клиент нарушает соглашение.
👉 2. "Удовлетворённость клиентов" / “Что всё хорошо работает” 👈
Это вообще другой пласт. И тут люди хотят магии:
- ничего не падает
- данные всегда тянутся
- любую свою поделку можно интегрировать за вечер
- саппорт отвечает быстро и по делу
Но это не про технику. Это про сервис.
Если хочешь метрику уровня "довольны — не довольны", проведи регулярный опрос вида «Кафка — заебись?». Никаких цифр в прометее не будет, но будет политический актив: аргумент на встречи с руководством и способ строить отношения с командами.
А если хочешь, чтобы эта метрика улетела в небеса — начни раздавать всем денег, вот радости-то будет!
А теперь о том, что реально можно померить.
Если хочешь именно технические метрики:
- latency контрольного приложения, которое пишет и читает тестовое сообщение — покажет по сути погоду на марсе, но прикольную
- доступность маршрута от контрольного клиента до брокеров — зависит от кучи других людей типа сетевиков, но тоже ничего так погода на марсе
- процент зелёных health-check’ов — не говорит ни о чём само по себе, но пускай будет
- размеры очередей — важно, но на практике всё сильно зависит от клиента
- падения коннекторов — 99% не зависящих от тебя, но пускай будет
Зачем? Чтобы показать “как хорошо мы работаем”? Нет, ни в коем случае!
Эти метрики могут дать ВНУТРЕННЮЮ пищу для размышлений: чтобы понять, где пора разгребать SRE-долг, как повлияли принятые решения, где искать рут коз стрельнувшей проблемы.
У продуктовых команд своя сказка, с этими метриками ВООБЩЕ не связанная. Они могут страдать даже при зелёной панели в графане.
⚠️ Важная мысль ⚠️
"Чтобы все были довольны" — это не инженерная задача. Это политическая. Игра про ожидания и договорённости.
Если хочешь работать над "удовлетворённостью" всерьёз — начинай с вопросов:
- Что именно пользователь ждал?
- Чем ты реально можешь управлять?
- Где заканчивается твоя ответственность?
- Кто будет эти ожидания формулировать и транслировать?
Это уже не про Kafka, а про продуктовое управление и лидерство.
Потому что да, если Кафка падает и теряет данные — пользователи точно будут недовольны. Но если она не падает и не теряет — довольными их это не сделает автоматически.😳
Всё остальное — коммуникация. И договорённости.
Если непонятно, как это построить — велкам на обучение руководству и тимлидству. Потому что никакие красивые метрики тебя от этих разговоров не спасут.
А какие критерии удовлетворенности работы Кафкой вы бы взяли? Уже вторую итерацию сомневаюсь, что хорошие выбрал.
Хороший вопрос. Но давайте сразу разберёмся — а мы про что именно?
Есть два совершенно разных уровня:
👉 1. Технические SLA 👈
Это твоя зона ответственности. Здесь всё предельно скучно и конкретно:
- гарантия сохранности и доставки сообщений (с кучей сносок и оговорок)
- работоспособность коннекторов и интеграций (Debezium и прочие)
- живые алерты и мониторинг (если упало — узнали)
- что интерфейсы мониторинга реально что-то показывают
- что есть возможность внести изменения в конфиги без плясок с бубном
Тут надо оговориться, что сохранность сообщений это сложная тема. Ты не можешь отвечать за приёмку чужих данных полностью — максимум за то, что, получив, запишешь их надёжно и сколько-то подержишь. Почему-то не очевидно, что “пуля вылетела со стороны моего приложения” — ещё не значит, что она долетела до хранилища. И обязательно надо формализовть: срок хранения, объём, всяческие оговорки вроде что происходит если клиент нарушает соглашение.
👉 2. "Удовлетворённость клиентов" / “Что всё хорошо работает” 👈
Это вообще другой пласт. И тут люди хотят магии:
- ничего не падает
- данные всегда тянутся
- любую свою поделку можно интегрировать за вечер
- саппорт отвечает быстро и по делу
Но это не про технику. Это про сервис.
Если хочешь метрику уровня "довольны — не довольны", проведи регулярный опрос вида «Кафка — заебись?». Никаких цифр в прометее не будет, но будет политический актив: аргумент на встречи с руководством и способ строить отношения с командами.
А если хочешь, чтобы эта метрика улетела в небеса — начни раздавать всем денег, вот радости-то будет!
А теперь о том, что реально можно померить.
Если хочешь именно технические метрики:
- latency контрольного приложения, которое пишет и читает тестовое сообщение — покажет по сути погоду на марсе, но прикольную
- доступность маршрута от контрольного клиента до брокеров — зависит от кучи других людей типа сетевиков, но тоже ничего так погода на марсе
- процент зелёных health-check’ов — не говорит ни о чём само по себе, но пускай будет
- размеры очередей — важно, но на практике всё сильно зависит от клиента
- падения коннекторов — 99% не зависящих от тебя, но пускай будет
Зачем? Чтобы показать “как хорошо мы работаем”? Нет, ни в коем случае!
Эти метрики могут дать ВНУТРЕННЮЮ пищу для размышлений: чтобы понять, где пора разгребать SRE-долг, как повлияли принятые решения, где искать рут коз стрельнувшей проблемы.
У продуктовых команд своя сказка, с этими метриками ВООБЩЕ не связанная. Они могут страдать даже при зелёной панели в графане.
"Чтобы все были довольны" — это не инженерная задача. Это политическая. Игра про ожидания и договорённости.
Если хочешь работать над "удовлетворённостью" всерьёз — начинай с вопросов:
- Что именно пользователь ждал?
- Чем ты реально можешь управлять?
- Где заканчивается твоя ответственность?
- Кто будет эти ожидания формулировать и транслировать?
Это уже не про Kafka, а про продуктовое управление и лидерство.
Потому что да, если Кафка падает и теряет данные — пользователи точно будут недовольны. Но если она не падает и не теряет — довольными их это не сделает автоматически.
Всё остальное — коммуникация. И договорённости.
Если непонятно, как это построить — велкам на обучение руководству и тимлидству. Потому что никакие красивые метрики тебя от этих разговоров не спасут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14