Я был программистом почти 1 год.
Как взрослый человек с СДВГ, естественно, я не обладаю такой же силой внимания к обычным вещам, как мои коллеги.
И я считаю, что катастрофа, вызванная мной, обычно вызвана тривиальной небрежностью.
Как и сегодня, я обнаружил, что процесс cron на сервере рухнул утром.
После получаса отладки. Я обнаружил, что написал в короне
* 4 * * * sh daily_task.sh
вместо
0 4 * * * sh daily_task.sh
Который запускает огромную оболочку 59 раз утром вместо предполагаемого 1 раз.
Есть ли какое-то культивируемое поведение или какие-то инструменты или что-то, что может помочь мне хотя бы уменьшить такую ошибку?
Как вы делаете, чтобы избежать такой ошибки?
Есть ли какое-то культивируемое поведение [...] это может помочь мне хотя бы уменьшить такую ошибку
Абсолютно, это называется принцип четырех глаз .
Если бы вы показали свой вход в кронтаб второму человеку (человеку, знающему, конечно, крона), шансы высоки, ошибки можно было бы избежать.
В программировании, когда дело доходит до этого, люди в основном думают о рецензиях на коды, но это на самом деле то же самое.
Вам не нужен СДВГ, чтобы иметь эту проблему. Возможно, вы работаете в среде, где вас часто прерывают или когда вам приходится работать над многими вещами одновременно. Таким образом, потеря пути вашего прогресса или небольшие ошибки почти гарантированы.
Есть одна вещь, которую вы можете сделать, чтобы уменьшить эти ошибки: тесты, основанные на спецификации.
Во-первых, вы записываете спецификацию самым подробным образом. В случае кода это должно быть в форме автоматических тестов. Лучший способ - следовать TDD. Поэтому, когда вы внезапно отвлекаетесь, ваши тесты скажут вам, что вы уже сделали, и позволят вам быстро подобрать, где вы закончили. Кроме того, это облегчает регрессионное тестирование.
В случае, когда код тестирования невозможен, убедитесь, что у вас есть кто-то, кто может просмотреть то, что вы создали, и попросить его протестировать программное обеспечение в соответствии со спецификацией. Вы всегда должны тестировать программное обеспечение в среде тестирования, прежде чем оно пойдет в производство. Проблема, о которой вы говорите, будет легко поймана, если вы проведете ее в течение дня в среде тестирования и проверите журналы.
Вы всегда должны быть как минимум в двух шагах от катастрофы. Это означает, что вы никогда не продвигаете что-то, что вы только что написали, в производство. Вы либо проверяете это, либо проверяете, либо проверяете, либо выбираете какой-то другой способ получить двухступенчатый путь к катастрофе. Иногда я оставляю что-то на следующий день и снова проверяю свою работу, прежде чем совершать.
В тех случаях, когда что-то действительно важно, вы добавляете третий шаг: второй рецензент, второй независимый тест и т. Д...
Человеку свойственно ошибаться. Наш мозг не создан для точности. Все делают ошибки, все пишут ошибки, хотя некоторые больше, чем другие (быть осторожным все еще платит). Вы должны выяснить процесс, который основывается на предположении, что работа любого человека ошибочна.
Предыдущие ответы упоминали два момента:
Отзывы.
Тестирование.
но есть и три дополнительных элемента, которые могут помочь:
Лучшая визуализация.
Используя инструменты, которые позволяют лучше визуализировать то, что вы делаете, вы можете уловить ошибки раньше. Это особенно показательно для работы с кронами. Представьте, что у вас есть инструмент визуализации, который графически показывает, когда выполняются определенные вами задания cron. Сразу же вы видите, что что-то не так.
Например, подсветка синтаксиса является наиболее популярным инструментом визуализации разработчиков, и он действительно помогает находить ошибки на очень ранних стадиях (часто в течение нескольких секунд после написания чего-либо неправильного) до запуска компилятора или тестов.
Непрерывный мониторинг.
Почему сервер рухнул? Разве не было способа увидеть, что что-то идет не так * до того, как произошли плохие вещи?
Серверы должны были должным образом контролироваться. Либо человек, либо приложение должны были видеть, что после последнего изменения использование процессора увеличилось, скажем, в среднем с 42% до в среднем 100%, и могло бы что-то сделать, чтобы предотвратить сбой сервера.
Это приводит меня к непрерывной интеграции и, более конкретно, к непрерывному развертыванию. В непрерывном развертывании, когда вы делаете коммит, новая редакция создается, тестируется и развертывается для производства на нескольких серверах. Затем эти серверы просматриваются приложением. Если приложение видит ненормальное увеличение использования ресурсов или ненормальное количество предупреждений в системном журнале, поступающих с этих серверов, серверы возвращаются в прежнее состояние.
Строгость.
Руководящие принципы и правила обычно раздражают (не убеждают? Попробуйте написать небольшое приложение C #, которое соответствует StyleCop и анализу кода и имеет хорошие результаты с метриками кода и имеет приличное покрытие кода!) но также особенно полезно. Вот почему некоторые проекты нацелены на нулевые предупреждения со статическими шашками и нулевые предупреждения с компилятором, установленным на максимальный уровень: ошибки, обнаруженные ранее, - это ошибки, которые вам не нужно решать, когда уже слишком поздно.
Хотя это не поможет с работой cron, это помогает при написании кода.
Я думаю, что прямое решение, особенно проблемы, которую вы иллюстрировали, состоит в том, чтобы делать ошибки заметными .
Если вы посмотрите на две строки, которые вы дали, разница на самом деле довольно тонкая. При чтении, если вы хотите уловить ошибку, вам нужно иметь много подробного, нюансированного синтаксиса «в уме». Вы также должны следить за трудно видимыми визуальными функциями (*
и0
можно легко спутать).
Например, в вашем примере, если синтаксис cron
был похож на следующий:
minute=0 hour=4 day=every week=every month=every year=every
Вы бы с меньшей вероятностью спутали это с:
minute=every hour=4 day=every week=every month=every year=every
Вы не можете изменить синтаксис cron, но вы можете написать для себя простую программу CLI, которая принимает именованные аргументы, как указано выше, а затем передает их фактическому cron
. Вы 'Нужно тщательно просмотреть код, который преобразуется из ваших именованных аргументов, но вам нужно сделать это только один раз, так что вы можете позволить себе по-настоящему сосредоточиться и пройти лишнюю милю при проверке ошибок - распечатайте код, прочитайте и объясните это себе вслух и так далее.
Когда у вас есть такая программа, вы также можете добавить проверку работоспособности. После того, как вы сделаете новую работу, выведите ее:
This new job will run 1 times a day.
(возможно, он пытается найти кратчайший период времени, который приводит к целому числу)
Теперь вам будет очень трудно совершить ту же ошибку. Ваш компромисс:
cron
был задан синтаксис, которым он был в первую очередь).Теперь я не обязательно предлагаю вам сделать это для "cron". Кажется, это немного излишне, если только вы не устанавливаете и не редактируете задачи на «cron» очень часто. Я просто использовал ваш пример, чтобы проиллюстрировать два полезных трюка: проверки Sanity и предпочтение синтаксиса, который делает ошибки очень заметными, даже если вы их не ищете. Идея состоит в том, чтобы убедиться, что ошибки запах.
С синтаксисом вы можете сделать две очевидные вещи:
Нет смысла делать это постоянно. Вы хотите спросить себя, что важнее в данной задаче: Правильность или ваше время? Бесполезно оспаривать, что взлом быстрого сценария в Perl поможет быстрее, чем написание хорошо структурированной программы C # с четкой иерархией OOP. Если вы не беспокоитесь об ошибках и спешите, зачем беспокоиться? Но имейте в виду, что каждый раз, когда вы берете этот ярлык, Вы делаете азартную игру: вы ставите много разочарований и скрежетаете зубами в надежде, что вы выиграли 'не нужно возвращаться и расширять свой проект в будущем, долго после тебя и № 39;Мы забыли, как это должно было работать (или что ты выиграл и № 39;на полпути понимаю, что ваш оригинальный дизайн выиграл и # 39;т работа, и теперь должны быть радикально изменены).
Я согласен со всеми другими ответами, но идея защитного кодирования также может помочь здесь.
При практике защитного кодирования мы пишем наш код в предположении, что он будет использоваться неправильно; будь то нами или кем-то еще. В этом случае ваш сценарий оболочки использовался неправильно (работайте 59 раз вместо одного раза).
Как мы можем защищаться от этого? Простой, но грубый способ - это записать метку времени где-нибудь в начале прогона и запустить ее только в том случае, если метка времени найдена и ей более 20 часов.
Проблема с этим грубым подходом заключается в том, что мы можем захотеть вручную запустить скрипт, например. если какая-то часть его функциональности должна быть запущена снова, но не все. В этом случае более детальный подход был бы лучше, например. «если последнему резервному копированию БД более 20 часов, сделайте резервную копию БД», «если последнее объявление было отправлено более 20 часов назад, отправьте объявление» и т. д.
А также тестирование...
Я обнаружил, что распечатывание кода на бумаге, затем запуск кода в отладчике и тикер каждой строки, как только я подтверждаю, что все значения были такими, как ожидалось в отладчике, были отличным способом. Это заставляет вас смотреть на ваш код другим способом .
Вождение «проверки отладчика» с помощью модульных тестов приятно...