Что будет, если из программиста сделать менеджера? Получится Engineering Manager — такой может и код написать, и Кафку починить, и из едва знакомых людей сделать крепкую команду.
Меня зовут Олег Федоткин и я Engineering Manager. В своем бложике я буду писать про:
- Менеджмент технической команды: как сделать так, чтобы ваши команды делали работу в срок и были счастливы.
- Архитектура (микро)сервисов: как не построить распределенный монолит и не скатиться в Big Ball of Mud.
- Инфраструктура: как победить кубер, зачем вам нужен service mesh и как развернуть 11 кластеров Postgres и выжить.
А еще про психологию, нейробиологию, влияние стресса на работу программиста и переговоры с людьми от бизнеса. И еще чуть-чуть краткого изложения книг, которые я прочитал и посчитал полезными.
Будет интересно :)
Меня зовут Олег Федоткин и я Engineering Manager. В своем бложике я буду писать про:
- Менеджмент технической команды: как сделать так, чтобы ваши команды делали работу в срок и были счастливы.
- Архитектура (микро)сервисов: как не построить распределенный монолит и не скатиться в Big Ball of Mud.
- Инфраструктура: как победить кубер, зачем вам нужен service mesh и как развернуть 11 кластеров Postgres и выжить.
А еще про психологию, нейробиологию, влияние стресса на работу программиста и переговоры с людьми от бизнеса. И еще чуть-чуть краткого изложения книг, которые я прочитал и посчитал полезными.
Будет интересно :)
🤝1
#longread #management #process #it
Что такое принцип Пока-Йоке и почему он вам нужен [6 минут]
Когда-то давно я работал в компании, чей продакшн сервер падал минимум по одному разу в неделю на пару часов. Иногда дольше — тогда мы отправляли гонца за энергетиком, а сами садились чинить до ночи, а то и до утра.
Я тогда был джуном и не совсем понимал, что происходит. Мои старшие коллеги старались писать код без ошибок, проверяли его перед отправкой в мастер и протыкивали руками функционал после деплоя на прод. Но мы все равно падали. Что-то шло не так, но что именно?
Тойота и принцип нулевых ошибок
Японцы из Тойоты еще в 60-ых годах очень хотели сделать свои автомобили качественнее и надежнее. Им нужно было побеждать США в борьбе за авторынок, а высокая надежность могла бы стать ценным преимуществом. Но на заводах Тойоты все еще работали живые люди, которые были обречены совершать ошибки. Чтобы обойти американцев, нужно было придумать что-то новое.
Тогда японский инженер Сигэо Синго сформулировать принцип Пока-Йоке: если человек обречен совершать ошибку, наши системы должны ему помешать. Например:
- На производстве Тойоты один тип гаек подходит только к одному типу болтов, перепутать невозможно.
- Некоторые детали взвешивают после производства. Если вес отличается от номинала, деталь спишут в брак.
- Сенсорные датчики, которые определят, что двигатель был собран неправильно.
Пока-Йоке — принцип, который превратил автомобили Тойота в самые надежные машины. Для себя я перевожу его так: нужно стремиться к построению такой системы, где человеческие ошибки будут предотвращаться самой системой. Если ошибку нельзя предотвратить, ее нужно обнаружить и указать на нее дежурному инженеру.
Как я использую Пока-Йоке в ИТ
Парни из истории в начале статьи про Пока-Йоке не знали и стремились не совершать ошибок, вместо того чтобы построить систему, которая не даст их совершить. Самый базовый пример: написать авто-тесты, но Пока-Йоке в ИТ применяется гораздо шире:
- Паттерн Circuit Breaker. У одного из наших партнеров висли сервера через день. Серваки отвечали не 400, не 500, а просто висли и отключались по таймауту. Трафика между нашими системами шло много (больше 1000 rps), так что зависание ТАКОГО количества тредов в таймауте приводило к деградации части системы. Тогда мы завезли Circuit Breaker, который теперь выключает все коннекты до партнера как тольк он виснет.
- Проверка обратной совместимости контрактов. Наши сервисы несколько раз падали из-за того, что один сервис обновил свой контракт и сломал второй сервис, который не может работать с новым контрактом. Мы встроили в наш CI/CD проверки, которые не дадут запушить контракты со сломанной обратной совместимостью. Программист может ошибиться, а наш CI/CD не может.
- Метрики и алерты из коробки. Все знают, что надо писать метрики и алерты на каждый сервис. А вот пишут — не все. У себя в компании я внедрил базовые метрики и алерты в каждый сервис, так что если кто-то выжрал весь CPU или течет по памяти, я про это узнаю.
Это только то, что влезло в пост :) На самом деле примеров гораздо больше.
tl;dr
Не пытайтесь не делать ошибок вообще. Создайте систему, которая не даст совершить ошибку вашим разработчикам. Если не получается, сделайте эту ошибку видимой. Например, напишите громкий алерт.
Ссылки
- [RU][Книга] Дао Тойота — если интересно, как Тойота стала такой крутой и вынесла весь автопром
- [RU] Подробная статья про Пока-Йоке
- [RU] Про паттерн Circuit Breaker
- [RU] Моя статья на Хабре об ошибках в разработке микросервисов
Что такое принцип Пока-Йоке и почему он вам нужен [6 минут]
Когда-то давно я работал в компании, чей продакшн сервер падал минимум по одному разу в неделю на пару часов. Иногда дольше — тогда мы отправляли гонца за энергетиком, а сами садились чинить до ночи, а то и до утра.
Я тогда был джуном и не совсем понимал, что происходит. Мои старшие коллеги старались писать код без ошибок, проверяли его перед отправкой в мастер и протыкивали руками функционал после деплоя на прод. Но мы все равно падали. Что-то шло не так, но что именно?
Тойота и принцип нулевых ошибок
Японцы из Тойоты еще в 60-ых годах очень хотели сделать свои автомобили качественнее и надежнее. Им нужно было побеждать США в борьбе за авторынок, а высокая надежность могла бы стать ценным преимуществом. Но на заводах Тойоты все еще работали живые люди, которые были обречены совершать ошибки. Чтобы обойти американцев, нужно было придумать что-то новое.
Тогда японский инженер Сигэо Синго сформулировать принцип Пока-Йоке: если человек обречен совершать ошибку, наши системы должны ему помешать. Например:
- На производстве Тойоты один тип гаек подходит только к одному типу болтов, перепутать невозможно.
- Некоторые детали взвешивают после производства. Если вес отличается от номинала, деталь спишут в брак.
- Сенсорные датчики, которые определят, что двигатель был собран неправильно.
Пока-Йоке — принцип, который превратил автомобили Тойота в самые надежные машины. Для себя я перевожу его так: нужно стремиться к построению такой системы, где человеческие ошибки будут предотвращаться самой системой. Если ошибку нельзя предотвратить, ее нужно обнаружить и указать на нее дежурному инженеру.
Как я использую Пока-Йоке в ИТ
Парни из истории в начале статьи про Пока-Йоке не знали и стремились не совершать ошибок, вместо того чтобы построить систему, которая не даст их совершить. Самый базовый пример: написать авто-тесты, но Пока-Йоке в ИТ применяется гораздо шире:
- Паттерн Circuit Breaker. У одного из наших партнеров висли сервера через день. Серваки отвечали не 400, не 500, а просто висли и отключались по таймауту. Трафика между нашими системами шло много (больше 1000 rps), так что зависание ТАКОГО количества тредов в таймауте приводило к деградации части системы. Тогда мы завезли Circuit Breaker, который теперь выключает все коннекты до партнера как тольк он виснет.
- Проверка обратной совместимости контрактов. Наши сервисы несколько раз падали из-за того, что один сервис обновил свой контракт и сломал второй сервис, который не может работать с новым контрактом. Мы встроили в наш CI/CD проверки, которые не дадут запушить контракты со сломанной обратной совместимостью. Программист может ошибиться, а наш CI/CD не может.
- Метрики и алерты из коробки. Все знают, что надо писать метрики и алерты на каждый сервис. А вот пишут — не все. У себя в компании я внедрил базовые метрики и алерты в каждый сервис, так что если кто-то выжрал весь CPU или течет по памяти, я про это узнаю.
Это только то, что влезло в пост :) На самом деле примеров гораздо больше.
tl;dr
Не пытайтесь не делать ошибок вообще. Создайте систему, которая не даст совершить ошибку вашим разработчикам. Если не получается, сделайте эту ошибку видимой. Например, напишите громкий алерт.
Ссылки
- [RU][Книга] Дао Тойота — если интересно, как Тойота стала такой крутой и вынесла весь автопром
- [RU] Подробная статья про Пока-Йоке
- [RU] Про паттерн Circuit Breaker
- [RU] Моя статья на Хабре об ошибках в разработке микросервисов
👍5
В дополнение к посту выше расскажу вам о гениальном применении Пока-Йоке. Правда, не в ИТ.
Представьте: завод по производству мыла. Типов мыла много, так что производственных линий тоже много, и все они в конце должны загрузить мыло в коробки. Проблема была в том, что в некоторые коробки мыло не загружалось и заказчику уезжала пустая коробка. Компания попадала на штраф и на повторную доставку одной-единственной коробки мыла.
Все осложнялось бюджетом: не было денег на дополнительное оборудование, которое хотя бы взвесит коробку и отбракует ее. Нанять человека будет дешевле, но ведь и он может пропустить пустую коробку. Что делать?
Тогда управляющий принес из своего кабинета вентилятор и расположил на одном из конвейеров. Поток воздуха из вентилятора сбрасывал на пол все пустые коробки, которые проезжали мимо. Компания закупила еще с десяток таких и решила проблему.
Представьте: завод по производству мыла. Типов мыла много, так что производственных линий тоже много, и все они в конце должны загрузить мыло в коробки. Проблема была в том, что в некоторые коробки мыло не загружалось и заказчику уезжала пустая коробка. Компания попадала на штраф и на повторную доставку одной-единственной коробки мыла.
Все осложнялось бюджетом: не было денег на дополнительное оборудование, которое хотя бы взвесит коробку и отбракует ее. Нанять человека будет дешевле, но ведь и он может пропустить пустую коробку. Что делать?
Тогда управляющий принес из своего кабинета вентилятор и расположил на одном из конвейеров. Поток воздуха из вентилятора сбрасывал на пол все пустые коробки, которые проезжали мимо. Компания закупила еще с десяток таких и решила проблему.
🤩1
#management #retention
Почему люди увольняются и как их удержать
Я минимум раз в месяц слышу фразу "этот человек нам нужен, давайте поднимем ему зарплату чтобы удержать". Зарплату поднимают, а человек уходит. Если зарплату поднимать не получается, менеджер опускает руки: единственный инструмент удержания не сработал.
В 2021-ом году ученые из малазийского университета провели исследование: какие факторы подталкивают человека к увольнению. Они собрали научные работы по теме увольнения и удержания, а потом свели причины в список. Вот он:
- Нехватка обратной связи — я видел команды, в которых люди ни разу не получали фидбек от руководителя, хорошо они делают свою работу или плохо.
- Недостаток обучения — сюда входит и обучение внутри компании, и покупка курсов извне, и обучение у коллег.
- Негатив на рабочем месте — слишком много конфликтов и/или подковерной борьбы, неравная оплата труда.
- Отсутствие доверия — излишний контроль убивает интерес к работе.
- Излишний стресс — если человек каждый день тушит пожары, он может пойти искать место поспокойнее.
- Слишком сложные задачи — иногда челленджа становится слишком много.
- Нет удовлетворения от работы — помните притчу про камни и храм? Это оно.
- Рабочее окружение — вот тут интересно. В английском "work environment" может значит и печеньки на рабочем месте, и правила поведения на рабочем месте. Вот подробности.
- Семейные проблемы — у меня есть пример, когда человека все устраивало, но они всей семьей переехали в другую страну.
- Низкая зарплата — да, из-за нее тоже уходят. Но не только из-за нее.
- Размер команды — люди в больших командах создают менее прочные горизонтальные связи, что плохо сказывается на социальном взаимодействии. Представьте: если вы общаетесь с коллегой раз в месяц, вряд ли вам будет так же комфортно, как если бы общались с ним каждый день.
- Из-за руководителя — не сработались, не сошлись характерами. Вспоминаю свою любимую поговорку: люди приходят в компанию, а уходят от менеджеров.
Мораль: если хотите удержать человека, помните про еще 11 (!) факторов помимо зарплаты, которые нужно прокачать. Займитесь обратной связью, убедитесь в его росте, проверьте задачи сотрудника, поинтересуйтесь как у него дела в нерабочее время. Не зарплатой единой удерживаем.
Ссылка на исследованиe
Почему люди увольняются и как их удержать
Я минимум раз в месяц слышу фразу "этот человек нам нужен, давайте поднимем ему зарплату чтобы удержать". Зарплату поднимают, а человек уходит. Если зарплату поднимать не получается, менеджер опускает руки: единственный инструмент удержания не сработал.
В 2021-ом году ученые из малазийского университета провели исследование: какие факторы подталкивают человека к увольнению. Они собрали научные работы по теме увольнения и удержания, а потом свели причины в список. Вот он:
- Нехватка обратной связи — я видел команды, в которых люди ни разу не получали фидбек от руководителя, хорошо они делают свою работу или плохо.
- Недостаток обучения — сюда входит и обучение внутри компании, и покупка курсов извне, и обучение у коллег.
- Негатив на рабочем месте — слишком много конфликтов и/или подковерной борьбы, неравная оплата труда.
- Отсутствие доверия — излишний контроль убивает интерес к работе.
- Излишний стресс — если человек каждый день тушит пожары, он может пойти искать место поспокойнее.
- Слишком сложные задачи — иногда челленджа становится слишком много.
- Нет удовлетворения от работы — помните притчу про камни и храм? Это оно.
- Рабочее окружение — вот тут интересно. В английском "work environment" может значит и печеньки на рабочем месте, и правила поведения на рабочем месте. Вот подробности.
- Семейные проблемы — у меня есть пример, когда человека все устраивало, но они всей семьей переехали в другую страну.
- Низкая зарплата — да, из-за нее тоже уходят. Но не только из-за нее.
- Размер команды — люди в больших командах создают менее прочные горизонтальные связи, что плохо сказывается на социальном взаимодействии. Представьте: если вы общаетесь с коллегой раз в месяц, вряд ли вам будет так же комфортно, как если бы общались с ним каждый день.
- Из-за руководителя — не сработались, не сошлись характерами. Вспоминаю свою любимую поговорку: люди приходят в компанию, а уходят от менеджеров.
Мораль: если хотите удержать человека, помните про еще 11 (!) факторов помимо зарплаты, которые нужно прокачать. Займитесь обратной связью, убедитесь в его росте, проверьте задачи сотрудника, поинтересуйтесь как у него дела в нерабочее время. Не зарплатой единой удерживаем.
Ссылка на исследованиe
🔥3👍2
#management #structure
Чем больше людей, тем больше хаоса в командах. Если компания растет по штату, но не перестраивает свою структуру, она обречена на сложности в коммуникации, функционал без владельцев и другие прелести дизорганизации.
Team Topologies — один из путей организации коллектива от 50-ти человек. Нужно разбить всю ИТ дирекцию на четыре подразделения:
- Stream-Aligned Teams (SAT) — кросс-функциональные команды продуктовой разработки, которые несут ценность клиентам. Например, пилят сервис доставки или корзины заказов. Таких команд должно быть большинство, процентов 60-80.
- Platform Teams — предоставляют SAT удобные и простые инструменты. Например, платформа строит CI/CD, дает возможность канареечных релизов, базовый мониторинг и упрощает работу с Кафкой. Если коротко: платформенная команда должна делать SAT приятно, а больше платформенная команда ничего не должна. В моей практике, на 10 человек в командах SAT нужно нанимать одного платформенного чувака.
- Enabling Teams — команды внедрения. Определение тут дать сложно, поэтому сразу пример: я руковожу платформой и мы сделали возможность канареечных релизов. Команды внедрения идут в проекты и помогают перевести сервисы на канареечные релизы. По размеру смотрите сами: я бы рекомендовал не больше платформенной команды.
- Complicated-Subsystem Teams (CST) — строит сложные системы и подсистемы. Например, аутентификация/авторизация на уровне всей компании или сервисы массовой рассылки. По количеству опять же смотрите сами: сколько у вас сложных подсистем и сколько на них нужно разработчиков.
Идея такого разделения в том, что Stream-Aligned чуваки доставляют ценность, а остальные им помогают и убирают преграды на их пути. При таком разделении продуктовые команды не отправляются пилить сервис рассылки СМС, за них это сделают CST.
Плюсы Team Topologies:
- Ускоряет доставку ценности: люди не путаются друг у друга под ногами, а работают в четких зонах ответственности
- Стабилизирует систему. Например, CI/CD часто являются общей болью. Если же вы выделите платформенную команду, у CI/CD появится владелец, ответственный за стабильную работу.
- Снижает бас-фактор. Помню, в одном из прошлых мест сервис по массовой рассылке делала продуктовая команда. Когда эта продуктовая команда встала и ушла, сервис тоже встал колом: как оказалось, без поддержки он не работает. В парадигме Team Topologies за такие проекты отвечает CST, которые обязаны шарить экспертизу внутри себя.
Минусы:
- Платформенная команда часто начинает думать, что она главная: платформа диктует свои условия и принуждает SAT к чему-либо. Повторю: главная цель платформы — обслуживать SAT и делать им приятно. Точка. Если так не сделать, платформа будет мешать поставке ценности.
- Появляется новый канал коммуникации и новая точка синхронизации. Например, раньше, если вам нужен был функционал в сервисе СМС, вы шли и делали. Теперь нужно заранее просить команды из CST.
Внизу — диаграмма для визуала.
Чем больше людей, тем больше хаоса в командах. Если компания растет по штату, но не перестраивает свою структуру, она обречена на сложности в коммуникации, функционал без владельцев и другие прелести дизорганизации.
Team Topologies — один из путей организации коллектива от 50-ти человек. Нужно разбить всю ИТ дирекцию на четыре подразделения:
- Stream-Aligned Teams (SAT) — кросс-функциональные команды продуктовой разработки, которые несут ценность клиентам. Например, пилят сервис доставки или корзины заказов. Таких команд должно быть большинство, процентов 60-80.
- Platform Teams — предоставляют SAT удобные и простые инструменты. Например, платформа строит CI/CD, дает возможность канареечных релизов, базовый мониторинг и упрощает работу с Кафкой. Если коротко: платформенная команда должна делать SAT приятно, а больше платформенная команда ничего не должна. В моей практике, на 10 человек в командах SAT нужно нанимать одного платформенного чувака.
- Enabling Teams — команды внедрения. Определение тут дать сложно, поэтому сразу пример: я руковожу платформой и мы сделали возможность канареечных релизов. Команды внедрения идут в проекты и помогают перевести сервисы на канареечные релизы. По размеру смотрите сами: я бы рекомендовал не больше платформенной команды.
- Complicated-Subsystem Teams (CST) — строит сложные системы и подсистемы. Например, аутентификация/авторизация на уровне всей компании или сервисы массовой рассылки. По количеству опять же смотрите сами: сколько у вас сложных подсистем и сколько на них нужно разработчиков.
Идея такого разделения в том, что Stream-Aligned чуваки доставляют ценность, а остальные им помогают и убирают преграды на их пути. При таком разделении продуктовые команды не отправляются пилить сервис рассылки СМС, за них это сделают CST.
Плюсы Team Topologies:
- Ускоряет доставку ценности: люди не путаются друг у друга под ногами, а работают в четких зонах ответственности
- Стабилизирует систему. Например, CI/CD часто являются общей болью. Если же вы выделите платформенную команду, у CI/CD появится владелец, ответственный за стабильную работу.
- Снижает бас-фактор. Помню, в одном из прошлых мест сервис по массовой рассылке делала продуктовая команда. Когда эта продуктовая команда встала и ушла, сервис тоже встал колом: как оказалось, без поддержки он не работает. В парадигме Team Topologies за такие проекты отвечает CST, которые обязаны шарить экспертизу внутри себя.
Минусы:
- Платформенная команда часто начинает думать, что она главная: платформа диктует свои условия и принуждает SAT к чему-либо. Повторю: главная цель платформы — обслуживать SAT и делать им приятно. Точка. Если так не сделать, платформа будет мешать поставке ценности.
- Появляется новый канал коммуникации и новая точка синхронизации. Например, раньше, если вам нужен был функционал в сервисе СМС, вы шли и делали. Теперь нужно заранее просить команды из CST.
Внизу — диаграмма для визуала.
❤1👍1