Автор Бергас Бимо Бранарто
За ростом нашей хоккейной клюшки стоят истории о рутинных неудачах. Мы не стесняемся говорить о том, что пошло не так - это то, как мы становимся сильнее, смелее.
В моем предыдущем посте мы говорили о том, как взломать наш способ все автоматизировать. Но иногда наши методы автоматизации терпят неудачу. И неудачи важны. Чем больше мы терпим неудач, тем быстрее растем. Вот как мы учимся - на собственном горьком опыте, на основе отзывов, ошибок и рекомендаций. Некоторые из наших ошибок:
Отсутствует лес за деревьями
Все началось с Стэна Марша - нашей устаревшей монолитной кодовой базы. Он был спроектирован и разработан с учетом того, что после того, как бизнес-процесс, связанный с функцией, определен, он никогда не будет изменен. Естественно, мы разработали его с жесткой структурой ООП. За этим последовал беспрецедентный рост и история рутинных неудач. Из-за этого мы постоянно находимся в пути экспериментов, за что пришлось заплатить.
Следствие того, как бизнес развивался, и жесткая структура кода сделали это постоянной проблемой. Часто код необходимо регулярно реорганизовывать на каждой итерации, что делает эту первоначальную ошибку серьезной.
Мы закончили тем, что нашли выход, добавив больше кода к существующему, чтобы избежать крупных рефакторингов.
В то время в нашей защите главное внимание уделялось скорости. Нам нужен был MVP, и нам нужно было многое сделать. Только позже мы поняли, что, добавив больше сложностей, в конечном итоге столкнемся с гигантской проблемой, на решение которой уйдут годы.
Никакого YAGNI мышления и разбитое окно
Когда мы кодируем, мы также пытаемся найти другой вариант использования, который может понадобиться, и включить его в код. Мы редко понимаем, как это может чрезмерно усложнить код. Мы также должны иметь возможность отслеживать охват кода, который увеличивает ценность бизнеса и операций - то, что нам не удалось.
Вам это не понадобится! Мы должны иметь возможность расти с помощью частых итераций обратной связи с минимальными усилиями. Мы не использовали этот образ мышления на начальных этапах.
Проблемы возникли, когда нам пришлось внести незначительные изменения; может быть новая функция или исправление, которое затронуло несколько доменов. Небольшая настройка здесь приведет к отключению всей системы. Он превращается в спагетти-код с большим количеством хаков, чем можно вообразить.
Прежде чем мы это осознали, мы опоздали. А теперь мы боялись прикоснуться к нему, потому что это сломало бы какую-то другую часть кода. В результате у нас было разбито окно. Когда нужно было поработать над дополнительными функциями, или когда новый участник присоединился к команде и начал писать код, разбитое окно может привести к появлению другого разбитого окна и т. Д.
Чтобы избежать разбитых окон, мы должны были более осознанно подходить к экспериментам или обновлению текущей логики. Но это легче сказать, чем сделать. В то время можно с уверенностью сказать, что наш код был попурри из «как не делать код». Но эти ошибки сослужили нам хорошую службу сегодня.
Нет дашбордов и системного мониторинга
Еще одна ошибка, которую мы совершили, заключалась в том, что мы понизили приоритет настройки дашбордов и предупреждений. У каждой системы есть ограничения. Что-то может пойти не так, когда система достигает своего предела, и никто не говорит вам, что система скоро выйдет из строя из-за этих ограничений.
Нам пришлось заставить машины сообщать нам, когда что-то пойдет не так, поэтому нам нужно настроить оповещения, чтобы предотвратить простои. При проведении рефакторинга нам также нужна была панель управления, чтобы получать отзывы о том, как рефакторинг влияет на систему. Мы должны определить, какой показатель мы улучшаем с помощью рефакторинга, и посмотреть, насколько он улучшится. Показателем может быть количество статусов ошибок, HTTP-ответов или количество увеличений пропускной способности по сравнению с количеством уменьшений запросов.
Проще говоря, мы не измеряли, насколько велика была наша система и как она себя ведет, потому что мы не оптимизировали то, что не могли измерить.
Чтобы измерить успех нашей оптимизации, нам нужно было сравнить значение до и после изменений. Это был важный урок в наши первые дни.
Нет настраиваемого пула соединений / потоков. Это также связано с ограничением системных ресурсов. Когда служба A обращается к чему-либо из службы B, она требует, чтобы ее обслуживали некоторые ресурсы B: файловая система, память, диск, потоки в процессорах, использование ввода-вывода и т. Д. Служба A также должна учитывать ограничение B, учитывая характер функциональность, которую он обрабатывает. Так что все нужно объединить и сделать настраиваемым. При хорошем мониторинге мы можем измерить его и при необходимости настроить для стабилизации системы в режиме реального времени.
Нет автоматического выключателя и механизма аварийного восстановления
Все, что может сломаться, сломается. Готовьтесь к неудачам. Нам необходимо определить, как система должна себя вести в случае определенного сбоя, каким бы он ни был.
В распределенной системе обмен данными между системами является одной из наиболее распространенных точек отказа. Время простоя является нормальным, учитывая ограничения системных ресурсов, количество транзакций, которые необходимо обработать, количество вышестоящих серверов, которые необходимо вызвать, все вместе и т. Д. Эти проблемы могут вызвать неожиданное поведение, если какая-либо последующая служба имеет медленное время отклика. Каждая восходящая служба должна определять максимальную продолжительность тайм-аута, которая обеспечивает ее собственную стабильность. Нам также необходимо рассмотреть механизм быстрого отката, если какой-либо нижестоящий сервер недоступен.
Нам также необходимо определить, как мы должны обрабатывать данные в случае сбоя в процессе транзакции. Следует откатиться? Следует ли нам оставить их, но пометить это как неудавшуюся транзакцию?
Нет стратегии архивирования данных или TTL, нет четкого определения использования
Хранение данных имеет свои ограничения. Мы используем базу данных и redis во многих местах. У каждого из них есть свои особенности отказа, если им не управлять.
Базы данных столкнутся с максимальным ограничением диска. Кроме того, если мы неправильно проиндексируем большие данные, это приведет к медленным запросам. Redis хранит данные на диске (если они сохраняются) и в ОЗУ (если они не сохраняются), они могут вызвать переполнение диска или нехватку памяти. Решения для обоих очевидны: нам нужно было управлять тем, сколько данных мы должны хранить в этих системах, и как сделать их согласованными во всех системах.
Были некоторые случаи, когда мы злоупотребляли одним экземпляром redis, который использовался для постановки сообщений в очередь, кеширования (поддержание временных данных для уменьшения количества обращений к db) и в качестве базы данных (хранения данных, которые упоминаются как часть определенной транзакции, без резервного копирования. в другом хранилище данных). Что мы будем делать, когда в этой коробке появится OOM? Очистить данные? А как насчет данных, для которых нет резервной копии? Что происходит с нашими данными обмена сообщениями, если они потеряны?
Нам нужно определять и разделять вещи на основе обычаев.
Это лишь некоторые из допущенных нами ошибок. В следующем посте я расскажу подробнее. Излишне говорить, что эти ошибки, ошибки в суждениях нам очень помогли. Мы стали сильнее, острее, больше готовы экспериментировать из-за этих неудач. О, и что замечательно в этих ошибках: они закреплены в наших Принципах проектирования. Мы не оглядываемся назад и не спорим о решениях. От нашего технического директора Группы Аджея Гор: Каждое решение правильное на момент его принятия. Один только этот принцип позволяет нам мыслить смело, брать на себя ответственность и масштабироваться.
Как видите, у нас достаточно сложных задач, которые нужно решить. Управление 18 продуктами и расширение в 4 разных странах сопряжено с множеством собственных проблем. Присоединяйтесь к нам. Помогите. Мы хотим, чтобы лучшие инженеры рассматривали GO-JEK раньше любой другой организации. Не упустите этот шанс, уверяю вас, он того стоит.
Чтобы просмотреть вторую часть истории, нажмите здесь.
