Устранение перебоев в производстве - сложная задача даже для опытного разработчика. Это надежный способ справиться с этим как профессионал.
В прошлое воскресенье мне срочно позвонил начальник. Релиз был в пятницу, но операционная группа только что обнаружила критическую проблему с приложением.
Я вздохнул, коротко пожаловался жене и вошел в систему.
Для разработчика необычно находиться в положении, в котором так велика неопределенность и давление. По мере продвижения по служебной лестнице это происходит все чаще и чаще. У меня были опытные наставники, которые научили меня надежному способу справиться с любыми остановками производства.
Произойдут перебои в производстве. Их можно разбить на 3 этапа: обнаружение, смягчение последствий и последующие действия. Каждая фаза имеет отдельный набор обязанностей и действий для разработчика.
Фаза открытия
Итак, я только что вошел в систему и сразу же позвонил своему боссу и нескольким членам группы поддержки, участвовавшим в эскалации проблемы. Сразу же ожидания возлагаются на меня, потому что я технический эксперт по вызову. Я должен определить основную причину проблемы. Мой босс любезно изложил мне проблему.
Сбой при создании отчета. Возникает исключение NullPointerException. Это строка кода и класс, откуда он был брошен.
- Мой босс
Мне сразу приходят в голову сотни мыслей. Связано ли это с релизом два дня назад? Что изменилось между тем, когда он работал вскоре после выпуска, и сейчас? Ни одно из изменений кода не коснулось этого компонента. Какова зависимость этого компонента от восходящего потока? Это ошибка пользователя?
Вы можете сразу почувствовать, что вашу репутацию нужно защищать, но преждевременное обвинение нанесет вам вред.
Вот первый важный совет: Во время простоя производства всегда предполагайте, что пользователь прав, и это действительно большая проблема. Легко сразу догадаться, что проблема не в ваше приложение. Это ошибка. Вы представитель своей команды. Не начинайте указывать пальцем, если не хотите нажить себе врагов. Это может легко нанести удар остальной части вашей команды - и вашей оценке эффективности.
Смирение
Вы должны оставаться скромными. Вы можете сразу почувствовать, что вам нужно защищать свою репутацию, но преждевременное обвинение нанесет вам вред. Сначала послушайте, послушайте еще раз и проведите собственное расследование, прежде чем заявить о первопричине проблемы.
Не бойтесь просить о помощи на этом этапе. В этот момент большинство участников телеконференции, не являющихся техническими специалистами, бездельничают, ожидая решения проблемы. Включение их в расследование не только поможет вам быстрее найти причину, но и укрепит чувство товарищества.
Может быть полезно порекомендовать разделить звонок на разные группы для более глубокого расследования или вызвать другого эксперта по предмету из вашей группы.
Когда вы достаточно уверены в первопричине, объясните ее другим участникам. Используйте простой язык и постарайтесь не делать никаких выводов о том, почему возникла первопричина. Как только я получил подтверждение от другого члена команды, что мой анализ первопричин верен, я был готов перейти к следующему этапу.
Фаза смягчения последствий
Я обнаружил основную причину и объяснил ее заинтересованным сторонам во время телефонного разговора, пришло время провести мозговой штурм. Мне сразу приходит в голову, как решить эту проблему. Я вкратце подумываю о том, чтобы предложить его более широкой группе.
В зависимости от ваших конкретных обстоятельств может иметь смысл немедленно принять меры для восстановления обслуживания пользователей и обсудить дальнейшие меры по снижению риска. Однако более вероятно, что есть несколько способов смягчить проблему со своими плюсами и минусами. Разные заинтересованные стороны будут по-разному оценивать относительный приоритет каждого из плюсов и минусов. Восстановление сервиса может даже не быть непосредственной проблемой. Важно узнать мнение всех заинтересованных сторон о возможных решениях и их последствиях.
В конце концов, вы, вероятно, не будете принимать окончательное решение. Но ваша работа - предлагать и объяснять различные решения, потенциальные воздействия и время восстановления. Сохранение непредубежденности позволит другим высказать свое ценное мнение и идеи. Это даст наилучшие результаты.
Вы не должны бояться высказывать собственное мнение. Ваш уникальный опыт и точка зрения станут неотъемлемой частью решения, независимо от того, является ли ваша точная идея тем, что в конечном итоге решит проблему. Также важно проявлять настойчивость и накладывать вето на все, что просто не сработает.
Как только стратегия смягчения последствий определена, выполните все необходимые технические действия для реализации стратегии. После того, как смягчение последствий завершено, вы должны перейти к последнему, наиболее важному этапу - посмертному электронному письму и последующим действиям.
Посмертное и последующее наблюдение
Я мог видеть, как солнце заглядывает в мое окно, снимая тяжесть стресса с моих плеч. Я был горд тем, что смог решить проблему до того, как это повлияло на бизнес.
Моя работа еще не сделана. Недостаточно уметь быстро решать проблемы. Более важно, чем решение проблем, в первую очередь предотвратить их возникновение. Вот где приходит посмертное электронное письмо и последующие действия.
Ваше посмертное электронное письмо должно содержать:
- Сообщается о проблеме.
- Основная причина проблемы.
- Что вы сделали для устранения проблемы.
- Что вы сделаете, чтобы предотвратить проблему в будущем.
На предыдущих этапах мы уже определили №1–3. Составьте их четко, используя маркированный список и примерный график.
Чтобы внушить спокойствие заинтересованным сторонам, вы должны точно описать, как именно эта проблема попала в рабочую среду. Вы должны указать факты о том, как это было пропущено на каждом пункте пропуска.
Платные ворота и профилактика
Плата за проезд - это то, как это звучит, шаг «останови и проверь». Платные шлюзы выявляют ошибки еще до того, как они начнут работать. Должно быть фактическое объяснение того, как эта ошибка прошла через каждую плату за проезд. Также, по возможности, включите дополнительный элемент для каждой платы за проезд.
Пакет модульного тестирования не охватил этот случай, потому что…
1. Внешняя зависимость не моделируется правильно в тестовых примерах.
2. Модульные тесты не улавливают границу между компонентами x и y.
3. Этот случай не рассматривался и поэтому не проверялся.
Тесты UAT не выявили проблему, потому что…
1. Среда UAT не была достаточно похожа на prod.
2. Тест не был завершен.
3. Тест не прошел, но был написан выключен как (ошибка пользователя, проблема с окружающей средой, проблема с качеством данных)
При проверке продукта после выпуска проблема не была обнаружена, потому что…
1. Эту проблему невозможно было воспроизвести в продукте.
2. Проверка не охватывала этот сценарий.
Это всего лишь несколько примеров. Убедитесь, что вы придерживаетесь фактов. Позвольте вашей аудитории сделать собственные выводы. Это отражает право собственности на ваш продукт и признание того, что у вас нет ответов на все вопросы. Смирение - ваш друг, и оно укрепит доверие у заинтересованных сторон.
Назначьте билет для каждого пропущенного пункта взимания платы и убедитесь, что ваша команда знает о билете, чтобы можно было установить соответствующий приоритет. Чтобы предотвратить повторение этой проблемы, вы должны выполнить изменения, которые вы изложили выше.
Возможно, проблема возникла до внесения необходимых изменений. В этом случае ваш скин будет сохранен, если у вас уже будет билет, объясняющий, как ваша команда собирается предотвратить повторение этого. Это свидетельствует о том, что вы не забыли продолжить наблюдение, а, скорее, просто не смогли завершить его.
Если, с другой стороны, вам не удастся создать соответствующие последующие действия, доверие заинтересованных сторон к вашему приложению резко упадет. Приложение будет постоянно помечено как «имеющее проблемы». Ваша команда, некомпетентная. Совершить ошибку один раз - понятно. Если вы и ваша команда не извлечете уроки из этого, это нанесет непоправимый урон вашей репутации.
Заключение и выводы
Производственную проблему можно разделить на три отдельных этапа: обнаружение, смягчение последствий и вскрытие. На каждом этапе от вас как от технолога требуется:
- Сохраняйте хладнокровие перед лицом давления.
- Имейте смирение под огнем.
- Объясняя технические вопросы, говорите четко и просто.
- Утверждайте себя и будьте уверены в своих знаниях и идеях.
- Возьмите на себя ответственность за ошибки своей команды.
- Принятие мер по проблеме надлежащим образом.
Первоначально опубликовано на https://alexpower.me 17 октября 2020 г.
