Всем здравствуйте!
Меня зовут Роман и я работаю в среднего размера компании (~500 человек), которая предоставляет консалтинговые услуги по разработке высоконагруженных систем для крупных компаний на американском рынке. Одним из клиентом является компания, которая входит в ТОП-5 крупнейших интернет-магазинов Соединенных Штатов по продаже одежды, обуви, галантереи и прочего ширпотреба.
Помимо нашей компании, консалтинговые услуги компании-заказчику предоставляют еще штук 12-15 крупных вендоров, работающих на постоянной основе, плюс куча мелких. Большое количество этих самых вендоров (как крупных, так и мелких) имеет аутсорс на полуострове к юго-западу от Китая. Традиции и ментальность в Индии существенно отличаются от нашего, и еще более существенно отличаются от западного, поэтому с завидной регулярностью по ходу работы возникает масса забавных и не очень ситуаций, для описания причины которых лучше всего подойдет нерусское слово «miscommunication». Этот опус, однако, не о работе с командами других культур, разбросанных по всему земному шару, а о том, что этот самый miscommunication легко может возникнуть на ровном месте даже в рамках одной компании, сотрудники которой разговаривают на одном и том же языке, а также о важности понимания контекста при общении с другими людьми.
Немного контекста
Система, над которой мы работаем, большая, компонентов много. Основной веб-стор крутится на кластере, содержащий порядка 80 машин, более мелкие системы работают в кластерах из 5-15 серверов. Необходимо все это для того, чтобы все приложение работало исправно при пиковых нагрузках. Теоретически, любой из компонентов может дать сбой, поэтому система проектируется таким образом, чтобы отказ какой-либо подсистемы не привел в сбою в работе всей системы, и тем самым не повел за собой срыв продаж, которые идут 24/7/365 и являются основным источником прибыли заказчика. Как говорится, мастерство программиста не в том, чтобы писать программы, работающие без ошибок, а в том, чтобы писать программы, работающие при любом количестве ошибок. Если я правильно помню, availability приложения за 2015 год сейчас находится в районе 99.98%, что для данного типа систем очень даже.
По контракту наша компания имеет так называемым ownership над рядом компонентов в системе. Заключается это в том, что мы отвечаем за разработку / внедрение / сопровожение / расширение каких-либо программных модулей, и никто кроме нашей команды разработчиков не лезет в код этого модуля без нашего разрешения. Ну, это по идее не лезет — учитывая географическое расположение остальных вендоров, их пробивную энергию и регулярное желание срезать углы, на практике этого достаточно сложно добиться.
Чтобы вести параллельную разработку многих модулей, инфраструктура предусматривает много энвайроментов, на каждом из которого крутится либо полная копия web-store’a, либо какая-то его часть. Ну, как много. Реально штук 150-200. Все энвы поддерживаются и развиваются нашими же DevOps и NOC (Network Operation Center) командами, обязанности которых заключается в том, чтобы все эны работали, имели задеплоеными требуемые версии компонентов, а если что-то упало — это что-то было быстро поднято, желательно без ущерба для разработки.
Поскольку доступность всех компонентов в продакшне критична для заказчика, наша компания предоставляет также услуги круглосуточного саппорта модулей, разрабатываемых нашими командами. Обязать поголовно всех разработчиков оказывать такой саппорт было бы не особо правильно, поэтому существует специальная команда SRE (Site Reliability Engineering), которая отвечает за L2/L3 саппорт. К чувакам приходят всегда с техническими проблемами в продакшне, и дальше они их решают. Обычно решение 95% проблем сводится либо к тому, чтобы дать рекомендации из серии: “А у вас тут один инстанс ушел из кластера, поэтому латенси и выросло на 20%. Рестарт в помощь.” (L2), либо: “Ой, да у нас же тут косяк в коде, мы щас посмотрим, как исправить по-быстрому. А если сами не сможем — позовем основную команду девелоперов, и подправим вместе с ними” (L3).
Заканчивающийся сейчас Holiday Season (Black Friday, плюс Cyber Monday, плюс несколько дней до и после) для ритейлинговых компаний — это счастье и боль в одном флаконе. С одной стороны, за эту одну неделю компания может сделать порядка 15-25% годовой прибыли. С другой стороны, безумное количество покупателей, желающих накупить кучу шмоток по скидкам, создают пиковую нагрузку и риск того, что какой-то модуль не выдержит нагрузки. Если компонент находится где-то далеко по стеку и являет собой, например, кеш уже совершенных заказов — это просто создаст неудоство командам обработки заказов. Если же вдруг ляжет сервис, который выполняет авторизацию платежных транзакций и покупатели почему-то не смогут отдать денюжки ритейлеру — мало не покажется никому, потому что сумма выручки за один день измеряется десятками миллионов буржуйских денег. Короче, Holiday Season, или, как его еще называют, пик — это крайне увлекательный, но напряженный период для всех, кто причастен к разработке и поддержке.
На пик SRE команда дает усиленный саппорт 24/7 и активно держат руку на пульсе всех наших компонентов. Для этого команда настроила себе на одном из таких энвайроментов разработки кастомный мониторинг компонентов в продакшне. По сути, написали маленькие утилитки, которые (в дополнение к основному мониторингу) регулярно шлют хитрые тестовые хелс-чек риквесты к каждой нашей системе, пишут какую-то статистику, а если вдруг один из компонентов начинает тупить и отвечать долго, или вообще не отвечать — сразу же громко кричит по всем каналам связи дежурным инженерам.
Энвайромент называется QI58. Формально, энв принадлежит SRE команде, т.е., по идее, никто кроме них (и DevOps/NOC команд в случае проблем) соваться туда не должен. Перед началом пика команда на всякий случай написала письмо всем нашим команадам, что QI58 mission critical, крутит важные сервисы, трогать его не надо, иначе будет атата.
Суть
Как-то так получилось, что также QI58 — это единственный наш нормально сконфигурированный энвайромент, на котором можно тестировать один из компонентов. Поэтому в обычное время этот энв шарится с нашей командой, и мы используем его для тестирования. Наша команда разработки последние пару дней занималась работой над небольшим улучшением именно этого компонента. Улучшение это с к пиком ничего общего не имеет, просто плановые работы по расширению. И сегодня стала необходимость протестировать его на энве. Мы написали СРЕ команде, что мол, не против ли вы, если мы сейчас проведем тестирование на QI58. Да-да, мы помним, мониторинг. Да-да, сделаем все аккуратно. Займет полчаса времени, по окончанию отпишемся.
А далее происходит примерно следующее:
- Один боец из моей начинает ручной деплоймент модуля на QI58 (да, автоматизированный деплоймент для этого компонента, увы, по разным причинам сейчас не работает). При попытке отправить тестовый curl запрос с этой же машины получает ошибку: sed: couldn't write 440 items to stdout: No space left on device. Понимает, что проблема скорее всего возникала из-за большого количества логов на диске, может повлиять на мониторинг, крутящийся на этой же машине, и говорит об этом мне.
- Соощаем о проблеме SRE команде. Говорим, у вас на машине проблема с местом, может быть критично для мониторинга.
- Получаем незамедлительный фидбек, что да-да, действительно критично. Также получаем добро на то, чтобы мы завели тикет в JIRA на NOC команду, чтобы чуваки посмотрели и решили проблему.
- Мой боец заводит тикет. Я на него смотрю, и понимаю, что, на всякий случай, надо бы еще раз напомнить, что QI58 является mission critical, и на нем крутятся важные приложения. Пишу коммент к тикету, в духе что: “NOC team, pay attention that this environment is highly critical. Please contact people A, B or C in case if you’re taking any actions that may affect availability of the instance”.
- Тикет берут в разработку, и через 10 минут он переходит в статус Resolved с комментарием примерно следущего содержания:
The problem is resolved by removing the following non-standard files and folders:
— gigaspace-monitoring.jar
— gigaspace-monitoring-libs/
— heartbeat.jar
~150mb was released. In case if problem appears again, please reopen the ticket.
Ну, а далее следует несколькочасовое всеобщее веселье, маты, и прочие радости жизни.
Lessons learned
Сразу скажу, что по-большому счету ничего страшного не произошло. Удаленные файлы были оперативно востановлены, никаких критических проблем с компоненами наблюдаемой системы за это время не произошло, ни один NOC-инженер не пострадал. Но тот факт, что из всего того, что можно было удалить на сервере, было удалено самое важное — это, конечно, эпик :)
Кстати, если подумать чуть глубже, то NOC специалист сделал то, что сделал, не ввиду своей глупости, и не потому, что забыл о том, что QI58 критичный энв, и даже не потому, что он дико везучий и ему на глаза в первую очередь попались файлы, которые трогать как раз не стоило. Корень проблемы оказался в том, что ему никто четко не скоммуницировал, какие именно процессы является критичными, и что именно не нужно трогать. При этом вся проделанная им работа была выполнена профессионально и в рамках инструкций:
- проблема была решена оперативно и качественно;
- сервер не был перезагружен, не был удален и создан с нуля из образа, и так далее. Т.е. availability энва не пострадало, как и требовалось;
- удалены были нестандартные компоненты, которые не являются приложениями, под который энвайромент изначально был предназначен;
- сразу после обнаружения проблемы команда NOC оперативно взялась за работу и восстановила удаленные компоненты.
Так что основные выводы, которые следует сделать:
- Не все то, что очевидно вам, очевидно другим людям в другой команде, занимающиеся другими вещами вне вашего контекста. А когда люди работают со сложными системами и большими обьемами информации, неполный контекст у конкретного человека — частое являение. Человек предполагает, что все в команде спецы и все работают с пониманием того, что делают, но упускает, что разные люди имеют разный контекст задач и не всегда полное понимание всех деталей, если он с каким-то элементом плотно не работал.
- Если что-то является mission critical, необходимо сделать не только так, чтобы все понимали, что оно таки mission critical, а ЧТО же именно является таковым (какие процессы ОС, приложения, файлы на диске, и т.п.). В дополнению к этому важно сделать так, чтобы были физические или процессуальные ограничения доступа, не позволяющие кому-либо навести беспредел там, где это важно. При этом всегда есть риск перегнуть палку и увязнуть в бюрократии, которая будет мешать нормальной работе, поэтому важен баланс.
- В каких-то случаях имеет смысл поговорить с людьми вживую, передать контект, и быть уверенным, что все поняли важные детали, прежде, чем начать стандартный процесс решения проблемы.
- Человеческий фактор — основная причина всех проблем. It is not about programming. Not about technologies. Not about business processes. It is all about people.
Общайтесь больше, формулируйте мысли четко и ясно, и помните о том, что картинка в голове любого другого человека всегда отличается от вашей.
Всем добра!
Автор: PingPong
