Распространенный страх начинающих IT-специалистов — ошибиться, сделать что-то не так. Но фейлы бывают у всех, даже у профессионалов. Мы собрали истории айтишников о том, как они ошибались, исправляли свои ошибки и чему учились на собственном опыте.
Свой путь iOS-разработчика я начинал с работы в небольшом стартапе. Меня пригласил туда мой одногруппник. Это было предложение, от которого, как говорится, невозможно отказаться: стартап, молодая перспективная команда из вчерашних студентов моего вуза, Apple-девайcы, которые я до этого видел только на картинках в интернете. Идея стартапа звучала инновационно — электронное меню для ресторанов. Воображение рисовало перспективы стать если не Стивом Джобсом, то как минимум Стивом Возняком. За все это еще и зарплату платить обещали. Разумеется, я согласился.
Это были ожидания, а теперь реальность. Вся команда программистов состояла из трех вчерашних студентов без опыта работы в своей сфере и одного, к счастью, опытного дизайнера. Каждый читал тонны мануалов и разбирался как мог, переступая с одних граблей на другие. Для основателя, у которого был ряд других, не IT, бизнесов, таких как завод строительных материалов, это было скорее хобби.
Монстр Франкенштейна, которого мы создали, был жизнеспособен, но любые исправления и доработки давались с большой болью. Сама идея электронного меню материализовалась в следующий пайплайн: над каждым из столов в ресторане спускается металлическая лапа с айпадом, посетитель делает заказ, и он поступает на кухню через ресторанную систему автоматизации iiko. Получается, чтобы запустить пилот, нужно было найти партнера, который согласится на такую интеграцию, включая установку дюжины металлических лап. Такой в конце концов был найден. Более-менее рабочая версия приложения была готова через полгода, но стартап завяз на стадии бесконечных доработок и улучшений.
Взяв волю в кулак и отринув мечту, я ушел в аутсорс-компанию. Опыт работы в ней над боевыми реальными проектами и общение с опытными коллегами за несколько месяцев дали мне больше, чем год в стартапе. Спустя несколько месяцев после моего ухода стартап закрылся, так и не дожив до своего первого теста.
Какие выводы я сделал? Очень важно, особенно на старте своей карьеры, попасть в хорошую компанию, которая делает качественные продукты. Такая компания даст понимание, что такое налаженные бизнес- и технические процессы, как на практике из них получается продукт. Необходимо, чтобы в этой компании были ребята с опытом, который как губке нужно впитывать, общаясь с ними и читая их код. Какая зарплата будет в этот период — неважно, важно получить опыт. Чуть позже, на этом месте работы или уже на следующем, он обязательно сконвертируется в хорошую рыночную зарплату.
Что касается стартапа — я думаю, критическими были две ошибки:
- Первая — это отсутствие опыта на всех уровнях. На техническим уровне помог бы улучшить ситуацию хороший, опытный техлид.
- Вторая — это скорость итераций. Необходимо максимально быстро сделать первую MVP-версию продукта и тестировать ее на реальных пользователях. Металлическая лапа сильно замедлила нашу интеграцию, и несмотря на то что программная часть продукта была в рабочем состоянии, лапа еще долго дорабатывалась, а попутно, само собой, придумывались и улучшения для приложения. Успешный выход из этой спирали улучшений, к сожалению, так и не случился.
В начале моей карьеры произошла неприятная, но поучительная история. Пропал исходный код мобильного приложения. В то время мы работали над большим и важным для компании продуктом: я занимался разработкой iOS-приложения, а мой коллега разрабатывал под Android. В тот день коллега, не поставив никого в известность, не пришел в офис. Насколько я помню, в тот день мы как раз должны были синхронизироваться по какому-то функционалу. Так как его не было в офисе, я решил сам посмотреть то, что мне нужно, в репозитории Android-приложения на BitBucket. Но был один нюанс — этого репозитория больше не было. Как выяснилось позже, от локального репозитория на рабочем компьютере этого разработчика тоже ничего не осталось.
Спустя несколько часов ситуация разрешилась в позитивном ключе: Android-разработчик приехал в офис компании к CEO и передал ему код на флешке (прямо как в кино). Но, разумеется, в компании работать перестал.
Эта ситуация привела меня к двум выводам: первый и более технический — следует с должным вниманием подходить к вопросам доступов и прав в сервисах, которые используются в компании. Второй — помимо контроля за сервисами и доступами, нам все же стоит быть внимательными к своим коллегам и сотрудникам.
В то время я работал младшим разработчиком в крупной российской компании в течение полугода. Сервис, в команде которого я трудился, был очень популярным и обрабатывал сотни запросов в секунду.
В тот момент мы (я и мой коллега, старший разработчик) разрабатывали новый микросервис, который уже частично был встроен в наш пайплайн (уже обрабатывал запросы из некоторых городов). И вот старший разработчик ушел в отпуск, оставив недоделанной фичу по включению нового большого города. И эта честь выпала мне. Я все подготовил и сначала выкатил в пре-продакшн. Все сработало. На следующий день я сделал все так же в продакшене, открыл панель с метриками и начал нервно нажимать на Ctrl+R. Через несколько минут начался рост метрики ошибок. Через 10 минут я начинаю откатывать свои изменения. Через 20 минут все вернулось в исходное состояние. В итоге примерно 15 минут пользователи в большом городе были без сервиса.
Этот опыт научил меня двум вещам:
1. Перед тем как что-то выкладывать в продакшн, нужно убедиться, что есть быстрый механизм отката изменений.
2. Делать процесс выкатки сервисов максимально автоматическим, чтобы было очень сложно что-то сломать.
Мы обновляли функционал по бронированию квартир в сервисе для агентов недвижимости.
Задача была довольно срочной, так как начинался горячий сезон осенью и покупатели квартир были более активны. Компания только настраивала процессы внутри отдела разработки, и важные детали порой ускользали. Я оценил предстоящий объем работы и пошел выяснять детали к продукту и ребятам, которые непосредственно использовали текущий интерфейс для работы.
У нас было три готовых флоу в старой версии компонентов. Столько же я перенес на новые компоненты и обновил логику, когда выяснилось что, оказывается, у нас теперь 12 флоу с сильно разной логикой, местами похожей. И разумеется, на остальные девять у нас нет макетов — их нужно сделать с нуля. Как так получилось? Проект переходил от одного менеджера проектов к другому без должной документации: на последнем этапе было совсем непонятно, как принимались решения раньше. Ну и, конечно, моя вина тут есть — я не погрузился в изучение задачи более детально перед ее выполнением и не изучил проблему со всех сторон перед оценкой сроков.
Что было дальше? Я, конечно, постарался объять необъятное и сделать макеты для всех вариантов развития событий, но потом мне пришла другая идея — не делать макеты!
В основном у нас использовались готовые компоненты, вопрос был только в логике. Поэтому, посовещавшись с разработчиками, мы решили максимально сосредоточиться на логике и описали все 12 флоу в большой гугл-таблице — с различными ролями, состояниями и максимально подробно. Разработчики успели в срок, а этот фейл позволил мне усвоить важный урок.
Изучайте вводные данные, задавайте вопросы, особенно внимательно относитесь к горящим задачам, которые нужно закрыть максимально срочно — нет ли там подводных камней? Если нужно, берите время на оценку сроков — это нормально и так нужно делать.
В 2007 году, когда я работал программистом в «еТелеком», появилась идея упростить подачу и обработку заявок для абонентов. Для этого мы дали им доступ в систему. Предполагалось, что клиенты будут сами создавать заявки из личного кабинета. Они автоматически начнут попадать в систему тикетов. Абоненты будут видеть статус заявки, комментарии специалистов и мгновенно получать ответы. Также клиентам будет доступна вся история их обращений. Решение казалось великолепным. Предполагалось, что время на обработку заявки, коммуникацию с абонентом и решение вопросов сократится в разы.
Разработали прототип, протестировали, провели инструктаж и запустили. Спустя пару дней я зашел в личный кабинет под тестовым логином и увидел в истории очень старые тикеты. Подумал: «Даже это показывает? Здорово!». И закрыл. Только через пару часов до меня вдруг дошло, что теперь и клиенты, которым мы дали доступ к истории обращений, видят старые заявки.
К сожалению, перед запуском обновления мы не провели целостный анализ. Времени на закрытое тестирование тоже не было. Никто не подумал, что помимо новых заявок, созданных самим абонентом, он видит и прошлые, связанные с его предыдущими обращениями до нововведения, а также комментарии к ним.
Сотрудники компании во «внутренних» заявках использовали сленговые выражения и локальные мемы. У специалистов техподдержки были свои любимчики, легенды о которых ходят по компании до сих пор. Поэтому комментарии вроде «Вечно баранит роутер» или «Пингуй-ребутай, доминируй-унижай» в старых тикетах встречались чаще, чем нам хотелось бы.
Когда проблему нашли, мы быстро установили фильтр, ограничили поиск и показ всех заявок в личном кабинете, кроме тикетов, созданных самим абонентом. В тот же день в компании появился регламент по тестированию и внедрению новых решений. Он состоял из нескольких этапов тестирования и дополнительных проверок. С тех пор техподдержке запретили писать любые комментарии, не относящиеся к делу, в любых, даже самых внутренних заявках. А мемы и сленг отправились в шуточный разговорник.
Совет для тех, кто не хочет повторить наш фейл: перед разработкой и запуском изменений, которые касаются пользователей, нужно трижды подумать, откуда берется информация и насколько она контролируема. Вспомните и проанализируйте все пути данных.
Я проработал несколько лет системным администратором. И, получив хороший опыт и довольных заказчиков, понял, что пора открывать свой бизнес.
Первое время брался за любую работу: хватал каждый заказ и пытался успеть все и сразу. Нужно было дальше расширять базу, завоевывать доверие клиентов. Так, неожиданно подвернулся срочный заказ. В одном из офисов в СПб клиент планировал открыть кол-центр на 18 человек. Помещение готово, для каждого сотрудника под заказ изготовлены столы. В них вмонтированы розетки 220В и двойная розетка с портами RJ-45 для подключения компьютера и телефона.
Моя задача — прокинуть кабель, обеспечить работу компьютеров и IP-телефонии. В таких случаях работа ведется по технологии PoE. Она позволяет помимо данных передавать и электрический импульс для питания устройства по одному кабелю «витая пара».
У меня было несколько дней — в понедельник кол-центр был должен заработать. Для монтажных работ я нашел пару ребят. Им было необходимо протянуть кабель к каждому столу, подсоединить его в розетку с одной стороны и в патч-панель с другой. Далее проверить все линии и запитать от патч-панели в стоечный коммутатор. Терминов много, но по факту работа несложная.
Ребята предложили мне кинуть по одному кабелю на каждое рабочее место и разбить его на два порта. Кабель «витая пара» состоит из восьми жил. Для работы в локальной сети любому устройству со скоростью 100 Мбит/с достаточно четырех жил. И порой для экономии времени и кабеля делают именно так — тянут один кабель и подключают два рабочих места или устройства. Мне идея понравилась, и я согласился.
На работу у ребят ушел весь день. Они начали с утра и закончили вечером. Я приехал с проверкой. Мы вместе пробежались тестером по каждому порту и проверили линии — все работало. Я оплатил работу и отпустил монтажников. Мне оставалось просто подключить компьютеры и IP-телефоны к сети. Я оставил это на следующий день.
Утром в субботу я занялся домашними делами, а в кол-центр поехал после обеда. Я подошел к первому столу и понял, что феерично сглупил. Дело в том, что для работы телефона по технологии PoE необходимы все восемь жил кабеля — первые четыре жилы отвечают за передачу данных, а вторые — за питание. А мы, как вы помните, решили сэкономить и разделили кабель на два рабочих места. В итоге получалось, что компьютер работает, а телефон нет.
Это было эпично. Я давно так не ошибался, но понимал, что это только моя вина. А значит, и исправлять мне. На всю работу у меня оставался один полный день, так что заниматься самобичеванием было некогда. Подвести клиента и испортить себе репутацию я не мог.
В итоге все воскресенье я заново прокидывал кабели по помещению, отрывал жилы от розеток и патч-панелей, снова все кроссировал, проверял и подключал. Я потратил весь день и, конечно, все дополнительные расходы взял на себя, так как вина была полностью моя. В понедельник кол-центр начал свою работу. Клиент остался доволен.
Какие уроки я извлек? Спешка — наш большой враг. Особенно когда речь идет о проектировании.
После окончания колледжа я устроился фулстек-разработчиком в компанию, владеющую магазинами электроники с филиалами по всей стране.
В основном я писал на PHP. Спустя несколько месяцев мне поручили задачу. Нужно было написать фоновый скрипт, который делает выборку пользователей магазина на основе определенных условий (общей суммы покупок, даты регистрации и пр.) и создает для них специальные условия на следующие покупки. Скрипт должен формировать список для рассылки и добавлять пользователей в специальную таблицу.
В тот день тестовый сервер не работал. Сроки горели, поэтому пришлось запускать сразу на продакшене. У нас была тестовая база со списками адресов, на которой мы обкатывали разработки. Для нее была сверстана какая-то страница. Ее я и использовал. Запустил скрипт, он обработал пользователей и добавил обработанный список в базу для тестовой рассылки.
Вроде все работало отлично. Но в этот же момент отдел маркетинга тоже экспериментировал с тестовой рассылкой. Вышло так, что эта непонятная тестовая страница с текстом, написанным просто так (насколько я помню, там была даже пара бранных словечек), начала отправляться десяткам тысяч клиентов.
Увидели мы это не сами. Нам позвонили коллеги из отдела работы с клиентами и сказали, что пожаловались уже два человека. Для меня это был верх стыда. Клиенты начали сообщать о спаме, а вернуть все назад было уже нельзя. Рассылку, конечно же, остановили. Но я был готов провалиться сквозь землю.
Какой из этого вывод? Нельзя тестировать на продакшене то, что не обкаталось в тестах. Даже если это небольшой скрипт. В тестовом сервере все переменные подконтрольны тебе, в продакшене куча переменных подконтрольны другим людями и похожи на случайность. Для себя я еще понял, что ребячество — это весело, но в коде, комментариях и прочем нецензурные и «веселые» названия переменных использовать нельзя. А для тестовой верстки придумали Lorem Ipsum (классический текст-«рыба», зачастую бессмысленный, который вставляют в макет страницы).
Раньше я работал над одним проектом по криптовалюте. Как-то раз выполнял задачу по выведению статистики — нужно было вывести историю цены монеты. В базе данных хранились вся информация, в том числе по ценам.
Пока работал с миграциями на локальной версии сайта, написал команду для очистки таблицы, а перед отправкой на продакшн забыл ее убрать. (Миграции используются для управления таблицей базы данных). Из-за этого на продакшене таблица полностью очистилась и данные исчезли. Сайт потерял внешний вид. В итоге мне помог коллега: он нашел резервную копию таблицы, загрузил ее на сервер и все заработало.
Чему научила меня та ситуация? Тысячу раз проверять все, что отправляю на сервер. И вам советую!
К нам обратился крупный FMCG-бренд за проведением чекового промо. Тогда, в 2018 году, это было в новинку. Загружаешь чек в чат-бот, ждешь модерации и получаешь приз. Перед нами стояла задача разработать платформу, состоящую из клиентской части (чат-бота), бэкенда по распознаванию фото, админской части, где будут сидеть модераторы, и отчетной подсистемы.
Запустились вовремя, по-другому не могло быть. Выдержали первую волну загрузок — все шло по плану.
Первый звоночек раздался от одного из модераторов: «У меня что-то подлагивает интерфейс, посмотрите, пожалуйста». Решили, что у него проблема с интернетом, и не придали значения. Затем при выгрузке статистики перестали открываться кабинеты модераторов. Система справлялась только с приемом фото.
Первичная диагностика показала, что не справляется база. Ее «повесил» запрос на отчеты. Переписали несколько запросов с Hibernate ORM (библиотека Java для решения задач объектно-реляционного отображения) на Native Query (запрос на чистом SQL) — проблема решилась. Можно двигаться дальше.
Через неделю ситуация усложнилась. Бот перестал принимать фото, то есть нарушился самый критичный процесс проекта. От гневных заявлений клиента спас триггер Zabbix (свободная система мониторинга и отслеживания статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования).
Мы приняли срочное решение заблокировать все модули проекта, кроме приема чеков от клиентов. В итоге мы смогли быстро решить проблему, инцидент был исчерпан. Помогло еще и то, что у модераторов были выходные, а «быстро поднятое не считается упавшим».
Что мы сделали не так? Выбрали монолитную архитектуру вместо микросервисной. Монолитная архитектура подходит под MVP (минимально жизнеспособный продукт) без пользователей. В других случаях нужно задуматься о микросервисах.
Истории подтверждают: ошибаться — это нормально. Главное — найти способ исправить ситуацию и сделать из нее выводы. Поделитесь в комментариях, какие ошибки вы допускали и чему они вас научили.
