Что будет, если из программиста сделать менеджера? Получится 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