Можно построить идеальную инженерную платформу, которой никто не хочет пользоваться! 😁 И самое забавное, что с точки зрения инженерных метрик у вас всё будет прекрасно! Короче, сходил я тут к ребятам из подкаста «В SREду на кухне» поговорить о том, зачем инженерам продуктовое мышление. И, кажется, это одна из моих любимых тем! Я вообще считаю, что одна из главных проблем платформенных команд — мы слишком часто думаем о том, что и как построить, и слишком редко о том, зачем это кому-то нужно. В итоге получаем технически прекрасные решения, которые либо никто не использует, либо используют исключительно потому, что выбора нет. О чём поболтали: 1. Зачем инженерам продакты? И в какой момент внутренний инструмент вообще становится продуктом? 2. Как измерять успех платформы? Вот у вас 100% adoption. Это успех или просто разработчикам запретили пользоваться альтернативами? 😁 3. Зачем нужны контрметрики? Можно же здорово ускорить разработку, а заодно уронить надёжность. Или сделать супернадёжную платформу, на которой невозможно работать. 4. Алертинг как продукт. Почему даже такую сугубо инженерную штуку можно и нужно проектировать вокруг пользовательского опыта? 5. Кто вообще заказчик надёжности? И почему пользователь, заказчик и тот, кто за всё это платит, — далеко не всегда один человек? 6. Что важнее — надёжность или Developer Experience? И почему вообще приходится выбирать между этими двумя вещами? Ну и поговорили про SLO, исследования пользователей, продуктовые метрики и прочие штуки, от которых у настоящего инженера иногда начинает дёргаться глаз. В общем, если вы строите внутренние платформы, инженерные инструменты или просто хотите понять, зачем в инженерных командах нужны продуктовые менеджеры — рекомендую посмотреть! Смотреть и слушать: 📺 YouTube 📱 VK Видео 📺 Rutube 🎧 Mave Ну и приходите в комментарии спорить!

#рецепт Что общего у ЦОДов Яндекса, концерта Канье и Cloudflare? Часть 1 Дорогой читатель, последние три дня урок катастрофы для многих. Яндекс сообщил о повреждении ЦОДов в Сасове и Калуге, затем во Владимире. При мне был также блэкаут, что перенёс концерт Канье, а сбой Cloudflare не только лишил клиентов доступа к сайтам, ну и случился прямо перед демо моего крупного OSS . Общее: ключевая опора проекта исчезает помимо твоей воли Проджектов учат управлять рисками: заболеет тестировщик -> сдвинется релиз. Человека можно заменить. А если недоступна вся команда и взять людей негде? Катастрофа редкое, часто невообразимое событие с последствиями на уровне компании и её репутации. Такое не внесёшь в реестр рисков и не добавишь в буфер пару дней. Нас не учат, что делать, когда план уже бессмысленен, люди сильно теряются Поэтому до кризиса я бы спрашивал себя не только "что может сломаться?", но и "что будет, если сутки нет платежей, связи с подрядчиком или доступа к продукту?". Вынести руководству варианты: резервный банк стоит столько-то; без него останавливаются платежи. Покупаем резерв или сознательно принимаем простой: предупреждаем клиентов, переключаем людей на другие задачи. Пусть ответственный за последствия подтвердит выбор печатно, что да принимаем, кто решил, когда пересмотрим. Хороший пример рекомендаций на такое в https://www.gov.uk/government/publications/orange-book, как муниципалитет должен реагировать на алярмы Проджект не может единолично принять риск для всей компании Когда катастрофа случилась, прежние сроки и обещания перестают быть планом. Нужен кризисный режим: эскалировать, назначить лидера с правом менять ресурсы, сроки и обязательства, фиксировать новые приоритеты и решения Есть полномочия -> действуй. Нет -> собери подтверждённые факты и неизвестное, назови ответственных, время следующего обновления и последствия для старых обязательств. Даже просто в моменте когда пахнет жареным дернуть лидов на синк посреди дня уже отлично, всегда можно извиниться если произошла ошибка, но такая реакция может сильно помочь в случае беды. Прокоммунцируй со стейкхолдерами, скажи: "Релиз в пятницу не состоится. Сейчас команда восстанавливает платежи; остальные сроки пересмотрим завтра, будем держать в курсе изменений" Хороший проджект должен понимать - людей очень пугает неопределенность и неизвестность. Страху отлично противодействуют: эмпатия, искренность, уважение, подотчетность и уверенность. Без ИБД Гасится паника: всем виден порядок действий, инженеров не дёргают лишними запросами. У Google SRE для этого отдельно разведены командование, восстановление и коммуникации Если вы сейчас вытаскиваете сервисы или людей из такого кризиса, сил вам