Как использовать японские подходы в IT. Часть 4: почему?

И один падающий лист предвещает наступление осени.

Японская пословица.

(こんにちは) Конничива! Я Виктор, менеджер проектов в Selectel. Это четвертая часть цикла про применение TPS/TBP (Toyota Production System/Toyota Business Practice) на практике в IT. Под катом разберемся с фундаментальными вопросами. В частности — о том, как вообще понять, что есть проблема, и нужно ли с ней что-то делать.

Недавно мой близкий задал вопрос: «Какую проблему ты решаешь?» И это сильно отличается от «европейского» взгляда, где скорее бы спросили «А чего ты добиваешься?» или «Какая цель твоих действий?». На первый взгляд — нюанс, но на практике именно разница в подходах может повлиять на то, будет ли решена проблема или создан еще один процесс ради процесса.

Вечный поток проблем

Как часто в жизни мы сталкиваемся с классическим «и так сойдет»? Разберем на примерах.

• Код сбоит → оборачиваем проблемный кусок в try-except. (Грешен, признаюсь!)
• Сервер генерирует слишком много логов → запускаем cron-задачу на очистку.
• Дома подтекает кран → кладем под него тряпку и отжимаем раз в день (а может и нет).

Общий знаменатель: мы устраняем последствие, но не причину. Конечно, «заплатки» иногда необходимы, но мы же не ставим запаску на автомобиль, чтобы проехать еще 10 000 км? Оно нужно чтобы добраться до шиномонтажа. Самое время вспомнить два базовых принципа из первой части: «пойди и посмотри» и «разберись в корне проблемы».

Разбираем пример

Рассмотрим «самый IT-шный» пример из упомянутых выше — починку крана. Каким будет стандартный алгоритм действий? Кран подтекает → мы подходим → проверяем, перекрыт ли кран полностью, → закрываем потуже.

Что сделает тот, кто «ищет виноватых» (назовем его управленцем-чайкой)? Кран подтекает → человек подходит к нему → проверяет, перекрыт ли полностью, → ругает домочадцев, что кран не закрыт.

Что важно: проблема вроде бы устранена, но если она повторится и старые трюки не сработают?

Как понять, что произошло

Для описания проблематичных ситуаций помогает правило 5W.

Теперь вернемся к нашему примеру с краном.

Вася мыл руки в уборной на втором этаже во время обеда (13:30) и заметил, что кран подтекает. После того как он закрыл воду, течь не прекратилась. В 16:30 Вася вернулся и снова увидел протечку.

IT-реальность

Окунемся в будни IT. Как часто выглядит диалог в чате:

— У нас прод упал!
— А что именно упало?
— БД отвалилась!
— Какая из?
— Та, что отвечает за логин пользователей.
— Это прямо сейчас?
— Нет, час назад.
— Кто-то что-то делал? Почему раньше не сказали?
— Да, Вася пересобирал индексы. Сказал, что это стандартная операция, и ждет завершения. Просил не паниковать.
— Мониторинг почему-то ничего не показал.

Что важно в этом примере.

• Коллеги знали детали, но сообщили их не сразу.
• Вопросы возникали частями, из-за чего диалог затянулся.
• Если бы информация была агрегирована, время на разбор сократилось бы в разы.

Вывод: Агрегированные данные сразу → меньше паники → быстрее находим решения.

Почему Вася положил прод

(скрипки из Хичкока)

Любые полезные действия и ошибки можно объяснить или даже оправдать. Но мы не будем углубляться в альтернативную медицину или теории заговоров. Нам интересны методы приобретения когнитивной ясности, а не как запутаться в искажениях.

Вопрос «Почему Вася положил прод?» можно разобрать с разных сторон.

Метод 5 Why

Для первичного анализа и сбора «анамнеза» используем уже упомянутое правило 5W. Его концепция проста: последовательно задаем вопросы «Почему?» до тех пор, пока не доберемся до корневой причины. У каждого могут быть свои формулировки, но главное — вовремя остановиться, чтобы не искать виноватых в Большом взрыве.

Карательная стратегия

Рассмотрим на примерах классическую «карательную» стратегию.

Пример №1.
— Почему Вася положил прод?
— Дурак! Уволить за профнепригодность!

Пример №2.
— Почему Вася пересобрал индексы?
— Дима сказал, что база тормозит.
— Почему база тормозила?
— Мало места на сервере — потом уже посмотрели.
— Почему мало места?
— Накопились логи.
— Почему накопились логи?
— APP слал много ошибок.
— Почему APP слал ошибки?
— Серёжа не выкатил новую версию.

Тут вы могли подумать, что второй пример закончится благоприятно, но единственная разница в том, что в нем уволили Серёжу. Но «наказать» — не значит исправить проблему. Базу починят, но через год ситуация повторится.

Спасательная стратегия

И снова рассмотрим на примере, но уже «спасательную» стратегию.

— Почему упала база?
— Вася пересобрал индексы.
— Почему он решил их пересобрать?
— В прошлый раз это помогло.
— Почему в прошлый раз это помогло?
— Потому что на базе все время что-то отваливается.
— Почему все время что-то отваливается?
— Она на CentOS6, мы туда кастомные пакеты льем.
— Почему там старый дистрибутив и пакеты?
— Не успели переехать на новый сервер.

Вывод: разворачиваем новый инстанс, переключаем коннекты. Все довольны… до следующего раза. Возможно, даже будет встреча-ретро, но скоро все про это забудут и Вася снова положит прод.

А был ли прод

Кажется, мы о чем-то забыли. Один важный момент из сценариев выше: мониторинг не выдал ошибку. Снова вернемся к 5W и нашему примеру.

— Who? Кирилл

— Where? В своем скрипте

— What? Получил ошибку

— When? Час назад, когда отправил запрос

— Why? 502-я ошибка, обычно такое бывает, когда Вася пересобирает индексы.

В этой ситуации, вероятно, был неверно распознан сигнал. А если система мониторинга (можно сказать, что это Андон из первой части) не выдала ошибку, то что произошло? И снова включаем режим «почемучки».

Базовый принцип работы Andon. Источник.

Почему мониторинг не выдал ошибку

— Почему мониторинг не выдал ошибку? Продовая база доступна.

— Почему мы уверены, что продовая база доступна? Приложения и микросервисы не сообщают об ошибке, пользователи тоже не писали, да и саппорт спокойно работает с порталом.

Так почему мы решили, что что-то упало? Оказалось, что пока Кирилл был в отпуске, URL базы поменяли. Васе повезло: он тестировал на предпроде. Кирилл же, который уже «тысячу раз обрывал провода» по поводу действий Васи, решил, что это был прод, и поднял панику.

Вывод: Кирилл не сделал «генчи гембутсу» — не удостоверился, что проблема реально есть.

Утрата фокуса

Частая причина подобных ситуаций — смещение фокуса. Человек — социальное и нервное (потому что социальное) существо, потому что склонен чуть более охотно запоминать негативные сценарии. На этом, в принципе, построено инженерное дело: мы улучшаем, потому что в прошлый раз просчитались. И хорошо, если никто не пострадал. Но инженеры часто мыслят результатом, а не процессом. Улучшения становятся побочным продуктом.

Если бы Волк не смог сдуть дом из соломы — никто бы так и не перешел на кирпич.

Сто шагов назад

Но что, собственно, фиксить в процессе, где «Вася положил прод»? Все довольны — ничего не сломалось. Ну скажут, что бывает, поменяют описание endpoint в документации — и все. Достаточно ли этого, чтобы ошибка не повторилась? Рассмотрим, как ситуация выглядела на самом деле.

1. ○ Вася «косячил».

2. ○ Кирилл ушел в отпуск.

3. х Кто-то поменял endpoint.

4. Δ Вася об этом узнал.

5. ○ Вася начал обновлять предпрод (бывший прод).

6. х Кирилл подумал, что прод упал, и поднял панику.

7. Истерика, потраченное время, трагедия, «контрмеры».

Идем по шагам назад и видим, что паника началась из-за шестого пункта. Очевидно, что Кирилл виноват — сам не проверил информацию, ведь так? Нет.

• По четвертому и пятому пунктам видно, что действия Васи не привели к проблеме.
• Третий пункт уже вызывает вопросы, но к нему мы вернемся.
• Второй пункт — Кирилл ушел в отпуск впервые за три года. Это нормально, отдыхать нужно.
• Пункт первый — Вася делал ошибки. Ну а кто не грешен? Пусть первым заставит меня разбираться в legacy.

Таким образом, проблема — между третьим и четвертым пунктами. Как Вася узнал о том, что endpoint поменялись? Вариантов много: разговоры в курилке, изучение конфигов и т. д. Значит, разбираем третий пункт. Рассмотрим примерный алгоритм, по которому в компании может проходить смена endpoint.

1. ○ Анализ потребности в смене endpoint.

2. х Согласование смены и дат смены.

3. Δ Оповещение всех интересантов, которые используют endpoint.

4. ○ Подготовка конфигов.

5. Δ Повторное оповещение всех интересантов, которые используют endpoint.

6. ○ Постановка задач на дежурных и смена endpoint.

О треугольниках, крестиках и кружках поговорим в будущей части. А пока можете делиться в комментариях идеями, что они могут значить.

Так что пошло не так

И снова используем принцип 5W, чтобы добраться до сути проблемы.

— Кирилл не знал о смене endpoint.
— Почему? Его не включили в рассылку (третий и пятый пункты).
— Почему? Он не входил в группу согласования.
— Почему? Никто не знал, что его сервис использует этот endpoint.
— Почему? Кирилл не рассказывал о разработке.
— Почему? В прошлый раз ему сказали, что он делает недоработанный продукт, а для согласования нужен готовый MVP.

Итог

Кирилл работал в «тихом режиме», не сообщал о своем кайдзене, не выяснил потребности компании, забыл оповестить тимлида и провести немаваши — обсудить все с командой. Как итог — поднял панику. Что сделали с Кириллом? Запретили заниматься разработкой вне его зоны ответственности.

Предлагаю в комментариях обсудить несколько ключевых вопросов.

• Правильно ли поступил тимлид Кирилла, запретив ему заниматься разработкой?
• Как в будущем избежать таких ситуаций с паникой и потерей времени при смене конфигов?

Ну почему

Жизнь несправедлива: делаешь — виноват, не делаешь — тоже виноват. Надо ли тогда вообще что-то делать? А что остается «погромисту-новатору»? Можем обсудить это в комментариях, а подробно отвечу на эти вопросы в следующей части. (またね) Матанэ! (Еще увидимся)