#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] Моя статья на Хабре об ошибках в разработке микросервисов