Термин «кайдзен» ввела компания Тойота, и про него много написано в толстенных книжках из серии «Дао Тойота».
Кайдзен еще называют «процессом непрерывного совершенствования». Обычно его ассоциируют с промышленным производством автомобилей и конвейерами, ну или как минимум с управлением процессами. Про разработку говорят мало, однако кайдзен очень хорошо подходит и для разработки ПО.
Далее Вы узнаете про несколько случаев, которые постепенно подвели автора к пониманию кайдзен в разработке.
Череда неурядиц
Первый случай произошел прямо в Новый год, в 20:00. На сервере сбойнул винчестер и из-за него пришлось отрываться от готовки салатов и срочно ехать в Москву на площадку обмена трафиком, чтобы поменять битое устройство.
После винчестера выгорела материнская плата. Всё поменяли, но потом решили разобраться почему так происходит.
Знакомые админы дали поняли, что нужно очень внимательно относится к серверному оборудованию, не покупать где попало и резервировать всё и на каждом уровне.
Решено было поменять сервер и очень внимательно отнестись к выбору поставщика. Посмотрели серверное оборудование, спросили рекомендаций и выбрали сервер, который в дальнейшем проработал без остановки и без перерывов 7 лет. Он и теперь продолжает работать, хотя прошло уже 5 лет после ухода автора с той работы.
Прошло еще какое-то время и на площадке произошёл пожар. Сервер чудом остался жив. Тогда все хорошенько перетрухнули, т.к. был риск полного уничтожения бизнеса.
После этого было сделано зеркало сайта и базы данных на отдельной, полностью независимой площадке в другом конце города. И однажды ей даже воспользовались.
Был также случай, когда на только что запущенный сайт начали пускать трафик, и вдруг он полностью остановился, просто не выдержал нагрузки.
После исследования стало понятно, что аутсорсинговая компании, создавшая сайт, сделала так, что он не держал больше 200 человек в день. Смешно и грустно.
После этого было решено отказаться от аутсорсинга и сформировать свою команду разработчиков.
Создав команду получили ещё одну проблему – исправление любой ошибки вызывало лавину новых ошибок. Любые изменения чуть ли не заваливали весь сайт.
Каждое исправление влекло за собой очень-очень много проблем. Когда проанализировали ситуацию, поняли, что нужно коренным образом менять вообще всё – все внутренности. И тогда был полностью отрефакторен весь сайт, с ног на голову поставлена вся его архитектура. И только после этого ситуация коренным образом изменилась и проблемы ушли полностью.
Исключить повторное возникновение корневой причины
Все эти решения объединяло одно – все они были нацелены на то, чтобы корневая проблема, лежащая в их основе, больше никогда не возникала повторно, чтобы она полностью была исключена. От слова совсем. И чтобы та же самая проблема больше никогда ни разу не повторялось.
Понимаете?
Элементарно: сбойнул компьютер — поняли, что надо выбрать правильное железо, которое не будет сбоить никогда.
Загорелась площадка — сделали её копию, чтобы исключить возникновение подобной ситуации в будущем.
Тогда и слова-то такого не знали – кайдзен.
5 почему
Не всегда корневая причина проблемы лежит на поверхности, иногда до неё приходится докапываться.
Хороший пример был приведен в одной из книг Дао Тойта.На производстве обнаружили, что один из станков простаивает большое количество времени в течение дня.
Почему у него перерывы в работе? Оказалось, что станок останавливается для уборки.
Вокруг станка наваливается стружка и грязь. Естественное, что если вокруг стружка, то её надо убирать, иначе работать невозможно. Всё верно?
Но кайдзен говорит: надо докапываться до корневой причины.
Почему наваливается стружка? Сразу приходит ответ: стружка наваливается из-за того, что она никуда не собирается – у станка нет устройства, которое позволило бы её отводить и собирать. Если бы такое устройство было, то станок не надо было останавливать.
Ну тогда давайте придумаем решение, которое бы позволило эту стружку отвести от станка и сделать так, чтобы он не останавливался для уборки вообще. Это решение уже чисто техническое и довольно простое.
Есть очень простая методика для определения корневой причины: известный метод «5 почему».
Кайдзен рекомендует его использовать, чтобы докопаться до глубинных причин.
Последовательно рассматривайте причины проблемы, одну за другой:
- Почему станок останавливается? Потому что производится уборка.
- Почему производится уборка? Потому что от станка летит стружка и грязь.
- Почему летит стружка и грязь? Потому что они не отводятся от станка.
С помощью «5 почему» находим корневую причину, придумываем решение, чтобы её устранить, назначаем ответственного и сроки и проверяем на еженедельной основе достижение результата.
Только учитывайте, что любую проблему можно решить как дорогими так и дешевыми способами.
Кайдзен говорит: сначала выбирайте самый дешёвый способ. Он обычно самый простой и самый лучший.
Кайдзен в разработке ПО
А теперь несколько недавних примеров из жизни команды, занимающейся разработкой ПО.
Фейловые джобы
Команда деплоит свои наработки в Прод запуская джобы Jenkins. По сути, Jenkins – это шедулер наподобие crontab, который может запускать джобы по расписанию. И такие джобы у команды были.
Однажды обнаружилось, что Прод-джобы свалились 5 раз подряд со статусом Failure. И никто не обратил на них внимание, при том что на деле каждый фейл на Прод должен быть всеобщей тревогой.
Тогда начали выяснять причину с помощью метода «5 почему»:
- Почему джобы зафейлились 5 раз и никто не обратил внимание? Потому что всем постоянно приходят уведомление о фейловых джобах, их очень много, и они примелькались
- Почему они примелькались? Потому что нам чуть ли не каждый день приходят какие-то уведомления, фейловые и не фейловые. Мы не видим разницы. Просто не обратили на них внимание
- Почему каждый день приходят уведомления? Потому что один из разработчиков тестирует новую джобу, которая валится, а уведомления об этом идут всем. Джоба не важная в данный момент, поэтому все перестали обращать внимание на уведомления от неё и заодно и от всех остальных джобов.
Решение было прозрачным: для тестовых джобов уведомление о фейлах вообще не будут высылатся никому, кроме самого владельца джобы, да и то если ему это надо.
Плюс официально было зафиксировано, что любое уведомление от джобов является исключительной аварийной ситуацией, на которую должны реагировать все.
Отвалившийся скрипт
Второй пример — проблема с приложением QlikView.
Однажды команде сказали, что их отчёты QlikView какие-то не такие. Вроде бы все работает, но данные не те. Начали разбираться в проблеме.
Оказалось, что скрипт загрузки не отработал до конца. Почему не отработал до конца? Потому что в скрипте было много кода и где-то посередине стоял отладочный оператор Exit Script — его просто забыли убрать, не заметили. Получилась ситуация, когда скрипт загрузки отвалился, а данные были использованы старые.
Почему этого не заметили? Потому что тестирование этого не показало из-за особенностей архитектуры. Приложение было разделено на две независимые части (бэк/скрипт загрузки и фронт) и т.к. данных было очень много, то их старались лишний раз не перезагружать, чтобы не терять на это много времени.
Специально было сделано так, чтобы фронт не был связан со скриптом загрузки. Он просто брал некий файл данных и показывал его. При этом не было понятно, что этот файл с данными старый, т.е в нём невозможно было определить наличие ошибки.
Что же было придумано, чтобы избежать в будущем повторения подобной ситуации?
Команда задала себе вопрос: как сделать так, чтобы заметить такую ситуацию в будущем? Как сделать так, чтобы было понятно, что скрипт загрузки не отработал до конца?
Решено было прописывать метку в начало работы скрипта, а в самом конце удалять её. Т.е. если метка не удалена, то это обозначает, что скрипт не отработал загрузку до конца. Фронт проверял, что если метка есть, то выводил красный баннер на пол страницы с уведомлением о проблеме.
Таким образом хоть и не была полностью исключена возможность возникновения подобных проблем, но по крайней мере о них сразу становилось известно. Дешевое простое решение.
Потеря данных при перезагрузках
Веб-сервис мониторинга принимал данные с промышленных стендов. Периодически его приходилось дорабатывать и исправлять, и каждое исправление требовало перезагрузки. Хоть перезагрузка и длилась пару секунд, но в это время гарантированно могли прийти промышленные данные и пропасть. Терять их было нельзя, поэтому команда решила проанализировать проблему глубже.
Вопросы «5 почему» дали понять, что корневой причиной проблемы является архитектура – именно она не позволяла сделать по-другому. Как бы не подкручивали сервис, что бы с ним не делали, всё равно всё сводилось к перезагрузке.
Новая архитектура решила проблему раз и навсегда — сервис был разделён на две независимых части, приём данных и их обработку. Эти части были физически отделены, т.е. можно было спокойно отключить обработчик, и при этом приём данных продолжал работать и сохранять всё, что к нему приходило. А самое главное, приёмщик данных был сделан так, что не требовал перезагрузки никогда. Обработчики же можно было спокойно отключать, дорабатывать и перегружать не заботясь о том, что данные могут потеряться.
DevOps вроде есть, но вроде его и нет
DevOps – волшебная вещь. Он вроде бы есть, но в то же время бывает и так, что его при этом нет.
Один из разработчиков выложил на тестовый стенд свои наработки. Несмотря на то, что он использовал DevOps, «вдруг» оказалось, что тестовый стенд подключился к боевой БД. Часть данных было безвозвратно утеряна.
Начали выяснять. Оказалось, что разработчик не заметил, что использовал боевую строку соединения.
Корневой причиной явилось то, что разработчику приходилось вручную менять строку соединения для разных стендов и серверов.
Что говорит кайдзен? Правильно! Надо придумать такое решение, чтобы полностью исключить проблему, т.е. убрать необходимость ручного изменения строки.
И решение было реализовано – строка соединения стала автоматически стала выбираться в зависимости от сервера, на котором была запущена. Проблема была решена раз и навсегда.
Думаю, Вы уже и сами поняли из приведенных примеров, что суть непрерывного совершенствования можно выразить одной простой фразой – полностью исключить повторное возникновение проблемы.
Ключевые результаты – неотъемлемая часть кайдзен
Результатом кайдзен является реализация, а не идея.
Придумать решение не так уж трудно, гораздо труднее реализовать его.
По каждому принятому решению важно поставить ключевые результаты, то есть понимать кто, что должен сделать и к какому сроку.
Как Вы поймёте, что достигли успешного результата?
Давайте возьмём пример со строкой соединения. Какой материальный результат здесь будет считаться успехом? Успех будет достигнут, когда:
- будет сделана библиотека для автоматического выбора строки соединения,
- разработчик встроит к себе библиотеку и успешно запустит с ней своё ПО.
Оба шага должны быть сделаны к определенному сроку определенными людьми. Только при выполнении обоих шагов можно считать, что успех достигнут.
Ключевые результаты – это критерии успешности, без них кайдзен не работает. Успех – это реализация.
Только реализованное решение позволит Вам исключить проблему в будущем, поэтому говоря про кайдзен всегда подразумевайте, что Вам придётся реализовать всё, что придумано.
Где еще это можно применить
Как Вы, наверное, увидели из примеров, кайдзен можно и нужно применять в анализе инцидентов. Собственно, он для этого и создан.
Инциденты в группах техподдержки, инфраструктуре и продуктовой разработке – идеально подходят.
Что касается кодирования, то и тут можно анализировать свой код и смотреть как его можно изменить, чтобы навсегда убрать найденные проблемы.
Да и те самые пресловутые Agile-ретро – это тоже кайдзен, ведь на этих встречах анализируются проблемы за спринт, задаются вопросы «5 почему», разрабатываются шаги по предотвращению проблем. Самый натуральный кайдзен!
Сама техника кайдзен в разработке ПО работает прекрасно, она очень простая в использовании и хорошо годится для использования в личных делах.
Секрет успеха прост: исключайте проблемы одну за другой и тогда их не останется совсем. Это и есть непрерывное улучшение.
Сама компания Тойота применяет кайдзен на производстве с ошеломительным успехом. Её результаты говорят сами за себя: брак производства — всего 1 деталь на 3 000 000 шт.
Почему бы не применить это для себя?
Теперь Вы официально прокачены. Если услышите такой термин –будете знать, что это такое.
И успехов Вам в работе.
Автор: varenich
