Этот пост изначально появился на jhall.io .
Одна привычка, которую, я думаю, каждый разработчик программного обеспечения, если не практически каждый профессионал в любой области, может извлечь выгоду из решения каждой проблемы дважды.
Вы также можете посмотреть видео, которое я создал по этой же теме, или пропустить прошлое, чтобы продолжить чтение.
Я помню, как впервые читал о похожей концепции в блоге Джоэла Сполского, Джоэл на программном обеспечении , где он написал Еще в 2007 году :
Почти каждая проблема технической поддержки имеет два решения. Поверхностное и непосредственное решение — просто решить проблему клиента. Но когда вы думаете немного сложнее, вы обычно можете найти более глубокое решение: способ предотвратить эту конкретную проблему снова.
Очевидно, я считаю, что этот принцип применяется не только только с обслуживанием клиентов.
Связанная концепция выходит из Toyota, Пять Почему Анкет Цитирование из Википедия :
При решении наблюдаемой проблемы, будь то в коде, бизнес -процессах или, возможно, даже протекающей раковине, мне нравится объединять эти принципы в технику, которую я называю «решать каждую проблему дважды».
Но, как и в случае с пятью, не берите «дважды» слишком буквально. На практике этот метод всегда должен давать минимум два решения, но часто приводит к 5 или более практическим решениям.
Шаги, по которым я следую:
1. Пятерка Вис
Используйте пять Способы определения множественных причин наблюдаемой проблемы.
2. Решите каждую проблему хотя бы один раз
Примените советы Джоэла Сполски по решению каждой причины хотя бы один раз. Каждая причина должна иметь немедленное исправление, и большинство также будет иметь как минимум одно более глубокое решение.
3. Повторите для процесса решения проблем
Снова пройдите первые два шага, на этот раз для процесса решения исходной наблюдаемой проблемы.
Чтобы проиллюстрировать эту технику на практике, позвольте мне описать проблему, с которой я столкнулся недавно.
Я хотел сделать обновление на одном из веб -сайтов, которые у меня есть, MinimalPairs.net , когда я столкнулся с проблемой. Я размещаю код для этого веб -сайта на Gitlab , где я использую Gitlab-ci для моей непрерывной интеграции и развертывания. У меня есть Gitlab-Ci, чтобы создать для меня среду обзора всякий раз, когда создается запрос на слияние.
Когда я недавно выдвинул изменения, я обнаружил, что обзорная среда не работает, и знаменитое предупреждение «Ваша связь не является частным» от Chrome, которое происходит, когда сертификат SSL сломается.
Я использую Давайте зашифруем , что я написано о ранее , чтобы управлять моими сертификатами SSL для меня. Иногда, чтобы получить новый сертификат, может потребоваться несколько минут, поэтому я был терпелив. Но через полчаса он все еще не работал, поэтому я знал, что у меня была законная проблема.
С небольшим копанием в моих журналах Kubernetes я нашел причину проблемы:
Status:
Acme:
Uri:
Conditions:
Last Transaction Time: 2019-11-18T08:41:49Z
Message: Failed to verify ACME account: acme: urn:ietf:params:acme:error:rateLimited: Your ACME client is too old. Please upgrade to a newer version.
Reason: ErrRegisterACMEAccount
Status: False
Type: Ready
Затем я посмотрел в конфигурации для моего кластера Kubernetes и обнаружил, что мне требуется версия 0.5.2 Cert-Manager упаковка.
helm install stable/cert-manager \
--name cert-manager \
--version 0.5.2 \
--set ingressShim.defaultIssureName=letsencrypt-prod \
--set ingressShim.defaultIssureKind=ClusterIssuer \
--namespace kube-system \
--tls
В то время было 0,11,0, поэтому явно обновление было в порядке.
С помощью непосредственных и коренных причин, давайте пройдемся по этапам, изложенным выше.
Наблюдаемая проблема заключалась в том, что сертификат SSL нарушен, что приводит к нашим первым почему:
1. Почему сертификат SSL сломлен?
Причина, как показано выше, заключается в том, что я использовал старую, неподдерживаемую версию пакета Cert-Manager. Это приводит ко второму, почему:
2. Зачем мне обновить диспетчер сертификатов?
Как вы можете помнить сверху, я явно просил версию 0.5.2 Cert-Manager упаковка. Возможно, было бы разумно всегда устанавливать последнюю версию.
Теперь я могу пройти через две проблемы, которые я определил выше, и решил решить каждую хотя бы один раз.
1. Установите последнюю версию диспетчера сертификатов
Это решит непосредственную, поверхностную проблему и снова заставит мой веб -сайт работать.
2. Больше не требуется определенная версия и всегда устанавливайте последнюю
Это предотвратит повторное представление проблемы в будущем. Конечно, это может открыть мою систему для нового риска, если новая версия Cert-Manager Каким -то образом что -то ломает что -то, но это может быть риск, который стоит взять.
Но не забудьте последний шаг! Повторите для самого процесса решения проблем.
В своем примере я нашел две области, где я считаю, что мог бы улучшить процесс решения проблемы.
1. Я должен был заметить проблему раньше
Я не обновляю MinimalPairs.net очень часто. Насколько я знаю, эта проблема, возможно, лежала в ожидании недель, прежде чем я попытался обновить и заметил.
Для этой проблемы приходят два возможных решения. Первый — это использовать простую службу мониторинга, чтобы предупредить меня, когда сертификат веб -сайта SSL больше не работает.
Во -вторых, и более активно, я мог бы использовать те же журналы ошибок, которые я использовал для отладки проблемы, и отправить их в такую услугу, как Sentry.io , который может немедленно уведомить меня, когда возникает проблема.
В духе решения каждой проблемы дважды я должен сделать обоими.
2. Это должно было быть легче найти журналы сбоев
Как только проблема была выявлена, отладка, это заняло больше времени, чем следовало бы. Это было во многом из -за того, что Kubernetes не хранит все журналы в централизованном месте. Это может быть решено путем настройки централизованной системы ведения журнала. Я уже использую Loggly Для большей части моего журнала я могу просто настроить его, чтобы отслеживать мои журналы Kubernetes.
Используя мою технику, я придумал пять потенциальных решений для простой проблемы с сертификатом SSL:
- Обновите менеджер сертификатов
- Не зависят от конкретной версии менеджера сертификатов
- Настройка мониторинга для веб -сайта
- Настройка ошибок оповещения
- Настройка лучшего регистрации
Применяя все пять из этих решений, я могу гарантировать, что я не только решил непосредственную проблему, но и улучшается общее здоровье всей моей системы, и следующая проблема, независимо от того, где это происходит в технологическом стеке, будет Это намного проще решить.
Оригинал: «https://dev.to/tinydevops/solve-every-problem-twice-4adb»