Несколько месяцев назад на Reddit появился пост разработчика начального уровня, который удалил производственную базу данных в свой первый день. Мы все съеживаемся, читая подобные истории о тех, кто совершает эти большие, незабываемые ошибки. Мы понимаем, что для этого не потребуется много времени - у большинства из них были близкие вызовы.
На моей первой работе старший администратор базы данных в первый же день отказался от производственной базы данных. Эти истории повсюду. Команда восстановила его ошибку из резервной копии недельной давности и держала его при себе. Спустя десять лет они все еще подшучивали над ним за это.
Однажды утром в начале этого года меня вызвали для решения производственной проблемы клиента. Они начали бета-тестирование своего сайта с небольшой аудиторией, когда в одночасье на главной странице их сайта ничего не было. Мне было интересно, была ли ошибка или уязвимость, которая привела к этому.
Я вошел в рабочую машину и открыл базу данных. Таблица статей была пуста. Хорошо, это подтвердило то, что мы видели на сайте.
В таблице пользователей остались пользователи. Странный. Таким образом, мы потеряли все наши статьи, но, по крайней мере, их бета-пользователи все еще имели свои учетные записи. Мы могли бы объяснить, что это бета-версия, и такое случается.
Следующие несколько мгновений были размытыми. Я точно не помню, что делал. Я не думаю, что был достаточно глуп, чтобы набрать drop table users в консоли. Но я был там, теперь без статей и без таблицы пользователей. Я немного посидел в шоке.
Тогда я подумал, как это исправить. Я действительно уронил таблицу пользователей? да. Мы делали резервные копии? Нет. Как мы можем сказать об этом клиенту? Я не знаю.
Я помню, как подошел к менеджеру проекта, сел рядом с ней и объяснил, что произошло. У нас не было данных в таблице статей, поэтому сайт выглядел пустым. И да, я тоже уронил таблицу пользователей. Теперь им нужно было повторно пригласить всех этих пользователей - если они смогут выяснить, кто они все. Ой.
Я вернулся к своему столу, чувствуя себя побежденным.
Однако что-то меня не устроило. Как мы вообще потеряли все эти статьи?
Я продолжал копать. Отчасти отрицание, отчасти желание сохранить лицо. Вскоре после этого я заметил кое-что важное.
На сервере было пять других баз данных. У одного из них было имя, похожее на имя базы данных, которую я только что просматривал.
Когда я его проверил, там были все статьи. Таблица пользователей была в порядке. Оказывается, изменение конфигурации случайно попало в рабочую среду, в результате чего сайт указывал на совершенно новую базу данных. Тех пользователей я видел? Данные о семенах.
Какое облегчение! Утро, полное нервов и желудочного сока, заставило меня почувствовать себя плохо, но мы смогли «восстановить» все данные, и я обнаружил настоящую проблему еще до того, как мы должны были сообщить плохие новости.
Много уроков извлечено из этого эпизода. Один из самых простых: теперь мы всегда делаем резервные копии… возможно, самый эффективный антацид для разработчиков.
Спешка и никогда не забегает вперед
Одна из других моих недавних ошибок, которая выделяется, была не столь драматична. Фактически, это была крошечная ошибка за крошечной ошибкой, которая в конечном итоге привела к беспорядку.
Нашей задачей был проект в сжатые сроки. (А разве не все?)
На нашей первой встрече мы как команда договорились, что это займет вдвое больше времени. Поскольку крайний срок давил на нас с самого начала, я быстро прошел через часть аутентификации, чтобы мы могли перейти к функциональности, которая действительно волновала клиента.
Раньше я реализовывал аутентификацию только один раз в одностраничном приложении и до сих пор не до конца понимал, как это должно сочетаться.
Какая ошибка - взломать его так быстро, как только смогу. Я пропустил несколько важных вещей:
- Пользователь загрузился из файла cookie после входа в систему, но страница попыталась загрузиться без ожидания. В зависимости от порядка этих событий вы будете получать ответы с сервера о том, что вы не авторизованы. Ошибка возникала редко, и ее трудно было воспроизвести, потому что большую часть времени все выполнялось в правильном порядке.
- Аутентификация также никогда не проверяла, истек ли срок действия токена. Если вы не заходили на сайт часто, когда вы вернетесь, сайт не будет работать, и вам придется выйти и снова войти.
- Токен должен был обновляться с каждым запросом, но у меня никогда не было времени разбираться в правилах, связанных с ним. Так что это снова привело к проблемам со сроками. Если мы отправили несколько запросов одновременно, в зависимости от порядка, в котором они возвращали, вы получите неправильный токен, который будет использоваться в будущих запросах.
Мы поспешили и все равно потратили вдвое больше отведенного времени. Разница заключалась в том, что ошибок было гораздо больше, а затем было потрачено еще больше времени на отслеживание и исправление этих ошибок.
Работа меня смущала. Затем, когда меня публично стыдили за это, все стало намного хуже.
Скажу одно: с тех пор я потратил время на изучение аутентификации. Теперь я понимаю OAuth, JWT, токены обновления и истечения срока действия. Я внимательно изучил код аутентификации, написанный другими в ряде библиотек. Я построил потоки аутентификации на нескольких разных языках и в разных фреймворках.
Превращение неудач в будущие успехи
Это единственное, что я убираю из всего, что идет плохо. Почти всегда из этого получается что-то хорошее, если хотите.
Если кто-то учится на своей ошибке, теперь он лучше, чем был раньше. Я стараюсь не обижаться на товарища по команде, который ошибается в первый раз. Обычно они уже знают, что напортачили.
Однако я стараюсь не быть таким жестким с теми, кто повторяет одну и ту же ошибку снова и снова. Они по-прежнему заслуживают сострадания.
Вы будете постоянно расти, если сможете делать четыре вещи с ошибками:
- смеяться над созданием одного
- учиться на этом
- дестигматизировать, делая их
- и поделитесь своей ошибкой, чтобы другие тоже могли извлечь из нее пользу
Я оставлю вам последний анекдот о ценности ошибок. Генеральный директор IBM в начале 1900-х Томас Дж. Уотсон однажды столкнулся с сотрудником, чья серия неверных решений дорого обошлась компании. Когда его спросили, собирается ли Уотсон уволить этого сотрудника, Уотсон ответил:
«Нет, я только что потратил 600 000 долларов на его обучение. Зачем мне нужно, чтобы кто-то нанимал его опыт? »
У вас была интересная ошибка в прошлом? Поделиться этим!
Спасибо, что прочитали статью! Если вы сочтете это полезным и хотите выразить свою поддержку, поделитесь им и не забудьте нажать кнопку 👏. Чтобы увидеть больше подобных статей, следите за публикацией и автором в Твиттере.
Зак Кун - директор по развитию цифрового агентства Smashing Boxes, Дарем, Северная Каролина. Он создает веб-приложения и мобильные приложения более десяти лет и участвует в стартапах и новых технологиях, таких как блокчейн, Интернет вещей и машинное обучение.
