1st Grammarly Anniversary

18/08/2020

Прошел ровно 1 год, как я присоединился к Platform команде Grammarly. Откровенно, это был ультра-стремительный год наполненный множеством событий и новшеств и хочется остановиться на мгновение и порефлексировать о том опыте, который я получил за это время. Думаю, что и так все знают, какой продукт создает Grammarly (а кто не знает, можно почитать тут), поэтому я больше уделю внимание внутренним процессам команды и постараюсь описать нашу кухню насколько это позволяет NDA.

Нашими заказчиками являются сервисные/продуктовые инженеры компании, которые находятся в офисах Киева, Сан-Франциско, Нью-Йорка и Ванкувера. Эти ребята пилят непосредственно 100+ сервисов, которыми миллионы людей пользуются каждый день. Они же представляют для меня воплощение DevOps методологии – весь жизненный цикл сервиса полностью лежит на их плечах. Разработчик сервиса не только дизайнит отказоустойчивое, масштабируемое, безопасное приложение, пишет целевой код, покрывает его автотестами, но также обеспечивает его инфраструктурами компонентами, мониторингом, алертингом, логированием и т.д. Да, это тяжело жонглировать таким кол-вом сущностей в каждом сервисе, но такой подход позволяет быть максимально автономным и убрать перекладывание ответственности с одного отдела на другой. Особенно это актуально во время решения проблем с незапланированными отказами обслуживания. Platform инженеры в свою очередь разрабатывают и внедряют автоматизацию во все процессы связанные с инфраструктурой и помогают остальным инженерам их успешно осваивать. Областью ответственности Platform команды являются облачная инфраструктура (AWS), инфраструктурные сервисы (GitLab, Artifactory, Graphite/Grafana, OpsGenie) и всевозможные инфраструктурные инструменты для внутреннего использования. Также мы тесно взаимодействуем с командой безопасности и комплаянса для обеспечения должного уровня защищенности инфраструктуры Grammarly.

Несмотря на бурный рост числа сотрудников в последнее время, структура компании остается максимально плоской. Каждая команда во главе с Engineering Manager может менять процессы внутри так, как ей удобно, и в целом открыто влиять на процессы всей компании через задокументированное предложение (Proposal aka RFC). Надо признать, что еще до моего прихода в компанию многие процессы уже были настолько отшлифованные и автоматизированные, что в период COVID пандемии компания достаточно быстро и легко перешла в режим удаленной работы без потери производительности. Внутрикомандные обсуждения, приоритизация, принятие важных решений ведется сообща. Ответственность за предоставленный сервис лежит на всех ее участниках. Внутри каждой команды есть дежурный инженер, который следит за исправной работой производственных систем и, в случае Platform команды, является первой линией поддержки.

Большинство сервисных команд работают по спринтам (2 недели) и достаточно оперативно доставляют изменения в продукт. Platform команда планирует проекты поквартально (3 месяца), т.к. зачастую эти проекты затрагивают всю инженерную составляющую компании и требуют существенных усилий и времени на повсеместное внедрение. За каждым проектом закреплен ответственный инженер (DRI), который драйвит множество стадий его жизненного цикла. Даже если над проектом работают несколько человек, то всегда есть тот, кто координирует и несет ответственность, а остальные участники ему помогают. В последнее время мы еще практикуем подход “наблюдательного совета” (Advisors) для уменьшения “замыливания глаза“, когда другие участники компании делают периодическую внешнюю оценку развитию проекта. Для того, чтобы лучше понимать масштаб проекта, приведу следующие примеры:

• Внедрение изолированных виртуальных десктопов (AWS Workspaces)
• Миграция сервисов в мультиаккаунтную AWS структуру
• Контроль исходящего сетевого трафика

Каждый Platform проект имеет приоритет и четкую цель дающую компании ощутимую выгоду – сокращение времени разработки сервиса, увеличение надежности системы, снижение рисков взлома системы или утечки персональных данных пользователей. Мы измеряем успешность проекта достижением ключевых результатов (Key Results). Я сам решаю как именно сделать проект, главное, чтобы разработанное решение таки решало поставленную проблему и соответствовало достаточно стандартным критериям (Production Checklist) – доступность, отказоустойчивость, масштабируемость, безопасность, покрытие мониторингом, логирование, обработка ошибок, наличие документации. В компании высокий уровень доверия сотрудникам, отсюда и высокий уровень автономии.

Platform команда автоматизирует свою работу в основном при помощи инструментов написанных на Go. Большинством провайдеров управляем через Terraform. Мы вообще очень трепетно относимся к Terraform и всячески топим за его вездесущее использование, но это отдельная тема. Максимально, где возможно, используем инфраструктуру AWS и стремимся к иммутабельности. Используем Packer + Ansible для сборки AMI. Почти все крутится в Docker на AWS ECS. Управляем армадой артефактов через On-Prem Artifactory и обеспечиваем непрерывную интеграцию с помощью GitLab CI/CD. Стараемся не делать вещи, которые уже сделаны хорошо кем-то еще. Кстати, только выбор вендора – это обычно целый проект в Grammarly. Проводится тщательный анализ кандидатов в несколько этапов, делаются на базе каждого PoC, часто ведутся переговоры об ограничениях/фичах с представителями. Очень круто, что у большинства вендоров компании есть контракты поддержки Enterprise уровня. Выделенные Slack каналы с AWS, GitLab, SumoLogic техподдержкой позволяют решать вопросы существенно быстрее писем в небесную канцелярию.

Кстати, в последнее время мы активно улучшаем документацию предоставляемую инженерам. На самом деле это очень сложный, но важный проект ^_^ Думаю многие сталкивались с быстрым устаревание документации. Чтобы держать ее актуальной, мы намерены прививать те практики, которые доказали свою эффективность в OSS проектах – линтинг наличия документации, code review checklist, diagram-as-a-code (PlantUML), Cloudcraft blueprints.

Отдельно хочется упомянуть про ценности (Values) в компании. Сначала я не придал им особого значения, но позже, анализируя критерии успеха компании, я понял их первостепенную значимость. Именно честность, позитивное мышление, страсть к общему делу, вежливое и эмпатичное общение, безобвинительная культура являются тем самым ключом к успеху. Нет, не технологии делают Grammarly столь крутой компанией, а эффективное человеческое общение. И это не культивируется на тимбилдингах, а распространяется как естественная среда в повседневной работе. Если возникает какая-то проблема, то обязательно кто-нибудь из команды отложит свою задачу и поможет тебе продвинуться дальше. Если случился непредвиденный отказ какой-либо из систем – все вместе ее чинят, анализируют причины и вырабатывают план устранения таких ситуаций в будущем. Каждый день мы тратим немало времени на то, чтобы поделиться друг с другом своим мнением, знаниями и последними новостями. Это позволяет оставаться в курсе событий и не выпадать из потока. В период удаленной работы в виду общеизвестных причин мы стараемся как можно больше переводить коммуникацию в асинхронный режим вдохновляясь примерами GitLab, HashiCorp, BaseCamp. Это любопытный сдвиг сознания, потому как в компании достаточно сильная позиция касательно работы в офисе, которая, я надеюсь, теперь поменяется.

Grammarly растет, растут и потребности команды. Уже полным ходом вся компания движется в мультиаккаутную AWS архитектуру и в ближайшее время будет распространяться в регионы за пределами США. Если Вам понравилось как звучит все описанное выше, то присылайте свое CV мне на мыло или подавайте заявку самостоятельно вот тут.