Блог компании mindbox

Школа разработчиков первый шаг к стажировке в Mindbox. Программа предназначена для студентов 34 курса и выпускников технических вузов с базовыми навыками программирования.
Первый набор Школы стартует 6 сентября, курс разбит на 8 занятий по 45 часов.

Чтобы записаться, оставьте контактные данные пришлем тестовое задание, рассчитанное на два часа. Но сначала убедитесь, что обучение в Школе разработчиков Mindbox это то, что вам нужно. Все подробности под катом.

Как появилась идея Школы разработчиков Mindbox

Стажеров мы набираем уже полтора года. Цель программы пополнить ряды разработчиков джуниорами. За это время с нами поработали 22 человека: шесть из них учатся прямо сейчас, еще шестеро устроились к нам в штат.

Чтобы молодым разработчикам было проще справиться с задачами на стажировке (а они не по силам многим начинающим), мы решили запустить бесплатную Школу, призванную помочь будущим коллегам со стартом карьеры. О том, как пройти путь от Школы через стажировку до трудоустройства, расскажу я разработчик и автор учебного курса Виталий Маргелов. Своим видением и советами поделится наш CEO Александр Горник.

О Школе разработчиков Mindbox

Чему и как обучаем в Школе

Обучение ориентировано на отработку современных подходов к .NET разработке, включает в себя практику объектно-ориентированного и функционального программирования на C# и Typescript, использования инструментов разработчика, активное изучение и применение принятых в индустрии практик командной работы (agile, scrum, code review, gitflow, continuous integration, continuous delivery). Главный навык после окончания курса умение писать полноценные веб-приложения с фронтендом, сложной бизнес-логикой и работой с базой данных.

План занятий

1. Базовые знания разработчика: цели, инструменты, основные понятия.
2. Что такое объектно-ориентированное программирование и почему оно важно.
3. Архитектура больших приложений.
4. Практические аспекты ежедневной работы программиста.
5. Процессы разработки и её место в компании.
6. Основы реализации собственного API.
7. Базы данных и работы с ними из C# кода.
8. Что бэкенд-разработчику нужно знать о фронтенде.

Расписание занятий

Первый набор Школы стартует 6 сентября, это воскресенье. Курс из 8 занятий по 45 часов (с перерывами, конечно) идет два месяца, приезжать к нам в офис нужно будет раз в неделю по воскресеньям. Приготовьтесь к интенсивной работе: в течение недели будет много домашки, около 15 часов.

О преподавателе (то есть обо мне)

Преподаю в Школе я, Виталий Маргелов. Общий стаж в коммерческой разработке около шести лет. До Mindbox три года разрабатывал высоконагруженные приложения в Лаборатории Касперского, полгода в CloudPayments, полгода занимался своей веб-студией. В Mindbox два года в роли разработчика, scrum-мастера и ментора стажеров.

Еще на третьем курсе обучения в родном НИТУ МИСиС я создал студенческую организацию, в которой четыре года преподавал программную инженерию и вел ИТ-проекты со студентами. Нами двигало желание научиться ремеслу разработки, но вуз этих знаний не давал. Нескольких месяцев работы в этой организации студентам хватало, чтобы обучиться основам, начать разрабатывать с нами коммерческие проекты или найти свою первую работу (и нашли её в итоге все). В Mindbox я стараюсь создать похожую среду, в которой студенты чувствовали бы себя вовлеченными, а свой труд ценным. На мой взгляд, это самое важное, чего не может дать вуз или самостоятельное обучение.

Как попасть в Школу

Чтобы попасть на обучение, нужно быть студентом 34 курса бакалавриата или выпускником технического вуза и обладать базовыми навыками программирования: уметь объявлять переменные, массивы и функции, писать циклы и условные операторы, понимать логические конструкции.

Для записи оставьте контактные данные отправим небольшое тестовое задание. Рассчитываем, что справитесь с ним примерно за два часа.

О стажировке в Mindbox

Из лучших студентов Школы мы отберем шестерых из них сформируем стажерскую команду, которая будет разрабатывать наш продукт. Гарантировать трудоустройство мы не можем, но у каждого стажера есть шанс попасть в штат. Если хороших кандидатов будет больше шести, рассмотрим вариант с формированием второй команды или останемся с ними на связи и будем приглашать на стажировку по мере освобождения мест.

Стажировка в Mindbox длится от трех до шести месяцев. Длительность зависит от общего впечатления от стажера оно складывается из того, как он справляется с задачами, прогрессирует, работает с обратной связью, способен ли выполнять работу без сверхопеки.
Стажировка оплачивается: 25 тысяч рублей при удаленной работе 20 часов в неделю и посещении офиса раз в неделю. Если нужно закроем производственную практику.

Разработка стажерского продукта не отличается от основного: в составе кросс-функциональной команды стажеры работают спринтами, реализуют новые фичи на бэкенде и фронтенде, чинят баги, проводят рефакторинги и оптимизации. У продукта есть реальные пользователи внутри компании, которые дают обратную связь и остро реагируют на неполадки, поэтому ориентироваться на бизнес мы учим с первого дня работы. Более опытным интернам мы доверяем самостоятельно принимать архитектурные решения в проекте и брать ответственность за успех целого спринта.

На прошлом месте работы задания выглядели, как лабораторные работы, расти было некуда. Я искал стажировку fullstack, и описание Mindbox меня зацепило.

Первое ощущение от офиса уют, от ребят открытость. Все как будто специально подобраны: готовые помочь, терпеливые. Первая задача, которую я взял в работу, оказалась очень объемной, и спринт мы завалили. Негативной реакции со стороны ментора не было мы просто обсудили, почему так произошло и какие нужно сделать выводы, чтобы такое повторялось реже. Думаю, это обычная рабочая ситуация в Mindbox: не всегда получается сделать обещанное.

Стажировка однозначно приближает меня к цели стать fullstack-разработчиком: каждая корректировка дает толчок. За первые три месяца здесь я узнал больше, чем за год на прошлом месте.

Рафик Абдряхимов, стажер

О трудоустройстве в Mindbox

Если мы довольны стажером, а в командах разработки есть места, пригласим кандидата на командное собеседование и, в случае успеха, в штат на 3040 часов в неделю. Все шестеро стажеров, которые перешли в штат, работают разработчиками, но мы готовы собеседовать и на младшие позиции product ownerа или SRE при наличии соответствующих наклонностей у стажера и запроса со стороны компании.

Я поступал в магистратуру МГТУ им. Н. Э. Баумана и искал стажировку, которая позволила бы совмещать работу и учебу. Про Mindbox ничего не знал, но вакансия показалась приятной, и я решил попробовать.

Стажировка оказалась очень полезной: для студента важно научиться взаимодействию в команде это нельзя узнать в теории, можно только попробовать на деле. Именно в Mindbox я первый раз увидел, как agile применяется на практике.

Стажировка помогла определиться с дальнейшим направлением работы: я узнал много тонкостей про С# (до стажировки моим основным языком был Python) и решил, что буду развиваться в С# и .NET. Сейчас работаю разработчиком и планирую дальше учиться и развиваться в будущем, возможно, дорасту до архитектора.

Тем, кто думает, идти ли в нашу Школу, я могу дать один совет идите! Вы получите мегаполезный опыт, научитесь крутым вещам и получите массу приятных впечатлений. Самые классные курсы в университете были те, где действующие разработчики делились опытом. Так и здесь: я видел программу Школы, она реально может заменить два года учебы в топовом вузе.

Юрий Соколов, разработчик Mindbox

Советы начинающих разработчикам от нашего CEO

Советую молодым ребятам и девушкам, которым нравится программировать, быть смелее. Постараться избегать частой ошибки умных интровертов недооценки себя. Коммерческое программирование несложная профессия с быстрым ростом, если вы готовы прилагать усилия и вам интересно.

Смелее откликайтесь, больше ходите по интервью, предпочитайте частные ИТ-компании, зарабатывающие на продаже ПО, небольших и средних размеров. Избегайте устройства на работу по знакомству (на кафедре посоветовали, ну я и пошел), государственных организаций и огромных корпораций, особенно банков. Также опасайтесь шальных денег в инвестиционных или нелегальных компаниях и прочем блокчейне. Ваш код должен выходить на продакшн и приносить деньги или видимую пользу.

Всё остальное вы сможете осознанно выбрать позже, когда разберетесь в рынке и поймете, что вам нужно. В начале карьеры очень важно заложить культуру, как с точки зрения техники (stack, инженерные практики), так и организационно (нормальный agile). Разница в производительности отделов разработки может быть даже не в разы, а на порядки. А из карьерных тупиков с возрастом выбираться всё труднее и труднее.

В нашей Школе и на стажировке, какой бы ни был исход, получите ценный опыт, обратную связь, знакомства и при этом заработаете немного денег.

Александр Горник, CEO Mindbox

Об IaC под Windows пишут мало, потому что DevOps/SRE ассоциируется в основном c Linux и Kubernetes. Мы решили исправить эту ситуацию и сравнить инструменты, которыми можно управлять IaC на базе Windows. Статья будет полезна разработчикам, которые работают с Windows-инфраструктурой и выбирают способы управления, и тем, кто уже внедрил Powershell DSC или Ansible, но сомневается в своем решении. Ниже поделимся опытом и расскажем:

• как устроен Powershell DSC и чем он отличается от Ansible при управлении инфраструктурой на Windows;
• почему мы перешли на Ansible;
• с какими проблемами столкнулись и как их решали;
• как соотносятся ожидания и реальность после перехода на Ansible;
• кому стоит выбрать Powershell DSC, а кому Ansible.

Почему изначально выбрали PowerShell DSC

В Mindbox развита культура DevOps/SRE, несмотря на преимущественно Windows-инфраструктуру: Hyper-V, IIS, MS SQL Server. И хотя компания постепенно переходит на Linux и Open Source, Windows пока превалирует.

Чтобы управлять этой инфраструктурой, планировали использовать инфраструктурный код: писать его, сохранять в репозиторий, а затем с помощью какого-то инструмента превращать код в реальную инфраструктуру. В то время как Ansible самый популярный инструмент управления инфраструктурой через код, он все-таки традиционно ассоциируется с Linux-миром. Нам хотелось что-то нативное и заточенное под Windows, поэтому выбрали PowerShell DSC.

Как работает Powershell DSC

PowerShell Desired State Configuration (DSC) это сервис, который уже есть в Windows из коробки и помогает управлять инфраструктурой через конфигурационные файлы. На вход он принимает инфраструктурный код на PowerShell, а внутри преобразует его в команды, которые конфигурируют систему. Кроме тривиальных операций, например установки Windows-компонентов, изменения ключей реестра, создания файлов или конфигурирования служб, он умеет многое из того, что обычно выполняется PowerShell-скриптами. Например, полный цикл настройки DNS или высокодоступный инстанс MS SQL Server.



Полезные ссылки к схеме:
Пример простой конфигурации для документов по DSC
Как использовать датафайлы
Как использовать SQL Server-базу в качестве бэкэнда для Windows Server 2019
Как настроить DSC pull server для работы с базой данных SQL для версий раньше Windows Server 2019

Чем DSC отличается от Ansible

Проблемы, которые возникли с DSC

Ожидания от DSC оправдались не во всём. Кроме этого, во время работы возникли новые потребности, которые не могли удовлетворить с помощью DSC.

Разработчики не могут использовать инструмент самостоятельно без помощи SRE. Хотя почти в каждой команде есть SRE, инструмент IaC должен быть достаточно простым, чтобы разработчик мог им пользоваться и тратить на это не больше получаса. DSC позволяет использовать не только декларативный код, но и любые конструкции на Powershell. Это значит, что высок шанс сделать код, который будет сложно сопровождать или который приведет к инфраструктурной аварии. Например, развертывание приложения с некорректными параметрами не в той среде.

Невозможно пропустить конфигурацию в режиме dry run перед прокаткой, чтобы увидеть, какие именно изменения будут применены, а какие нет.

Для DSC трудно организовать синтаксические проверки и проверки стиля кода. Инструментов для проверки мало, и они не обновляются. Для Ansible мы это уже сделали.

В push-режиме DSC нет удобного способа отслеживать состояние тасков. В случае если конфигурация применилась с ошибкой, для диагностики следует совершать дополнительные действия: выполнять команды, чтобы получить статус применения конфигурации, смотреть журналы событий. Если ошибка произошла на нескольких серверах, то это отнимает много времени.

Pull-режим так и не стал преимуществом. В нем конфигурация применяется асинхронно узнать, когда точно закончено применение новой конфигурации, невозможно без обвязок и костылей.

Избыточное использование двух отличных друг от друга инструментов IaC, которые конфигурируют серверы. Ansible может делать то же, что и DSC, а ведь мы уже используем Ansible для конфигурирования Linux-хостов и сетевого оборудования.

Как планировали перейти с DSC на Ansible

Сначала задача казалась простой, приблизительно на месяц. Мы выделили три этапа работ:

• научиться подключаться к Windows-хостам с помощью Ansible;
• переписать конфигурации DSC с помощью Ansible-модулей;
• удалить DSC pull server, его базу данных и прочие артефакты.

Вот какой рабочий процесс был на DSC, и как планировали организовать в Ansible:




Стандартная структура ролей в Ansible

На Ansible мы планировали отделить сложный код, который что-то конфигурирует и устанавливает, в код ролей и разнести роли по отдельным репозиториям. В главном репозитории Ansible должны были остаться только вызовы ролей, переопределения параметров ролей и списки серверов по группам. Так не только SRE, но и любой разработчик мог бы развернуть роль на нужные серверы или подправить параметр, не углубляясь в логику инфраструктурного кода. Исправить же код роли разработчик сможет только после ревью SRE.

С какими сложностями столкнулись при переходе на Ansible и как их решали

Когда работа началась, мы поняли, что ошиблись: задача оказалась непростой. Проблем не возникло только с репозиторием, а в других вопросах пришлось много исследовать и улучшать наработки.

WinRM или SSH

Первый сюрприз состоял в выборе типа подключения. В случае Windows их два WinRM и SSH. Оказалось, что Ansible медленно работает через WinRM. При этом Ansible не рекомендует использовать OpenSSH из коробки для Windows Server 2019. И мы нашли новое решение:

1. Форкнули и переделали под себя роль из Galaxy.
2. Написали плейбук, в котором есть только вызов этой роли. Это единственный плейбук, при котором идет подключение к хостам по WinRM.
3. Стандартными средствами Prometheus Blackbox Exporter сделали мониторинг порта 22/tcp и версии OpenSSH:
   
   - alert: SSHPortDown
expr: probe_success{job=~".*-servers-ssh",instance!~".*domain..ru"} == 0
for: 1d
annotations:
summary: "Cannot reach {{`{{ $labels.instance }}`}} with SSH"
4. Выбрали и настроили LDAP-плагин для инвентаризации, чтобы не вписывать вручную все Windows-серверы из домена в статическую инвентаризацию:
   
   plugin: ldap_inventory
domain: 'ldaps://domain:636'
search_ou: "DC=domain,DC=ru"
ldap_filter: "(&(objectCategory=computer)(operatingSystem=*server*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
validate_certs: False
exclude_hosts:
- db-
account_age: 15
fqdn_format: True
5. Развернули везде OpenSSH с нужными ключами и убедились, что ни одного алерта о недоступности Windows-серверов по SSH больше нет.
6. Чуть позже интегрировали установку OpenSSH в стандартный образ. Наши образы готовятся с помощью Packer, который также умеет вызывать Ansible:
   
   "type": "shell-local",
"tempfile_extension": ".ps1",
"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],
"env_var_format": "$env:%s=\"%s\"; ",
"environment_vars": [
"packer_directory={{ pwd }}",
"ldap_machine_name={{user `ldap_machine_name`}}",
"ldap_username={{user `ldap_username`}}",
"ldap_password={{user `ldap_password`}}",
"ansible_playbooks={{user `ansible_playbooks`}}",
"github_token={{user `github_token`}}"
],
"script": "./scripts/run-ansiblewithdocker.ps1"


Рефакторинг

Когда мы переписывали код под Ansible, то периодически натыкались на дублирование кода. Например, почти все конфигурации DSC содержали установку windows_exporter. Единственное, что отличалось это коллекторы, которые экспортер должен был использовать:



Чтобы избавиться от дублированного кода, вынесли windows_exporter в отдельную Ansible-роль, а параметры этой установки в переменные групп хостов.

Second hop authentication

Наверное, second hop authentication самая распространенная проблема, с которой сталкиваются те, кто начал использовать Ansible под Windows:

- name: Custom modules loaded into module directory
win_copy:
src: '\\share\dsc\modules'
dest: 'C:\Program Files\WindowsPowerShell\Modules'
remote_src: yes

Такая конструкция вызывает ошибку Access Denied из-за того, что по умолчанию делегировать учетные данные для авторизации на удаленном ресурсе невозможно без дополнительных настроек. Обойти ошибку помогает, например, new_credentials. Но мы предпочли воспользоваться тем, что Ansible умеет вызывать ресурсы DSC через модуль win_dsc. Вызываем DSC-ресурс File, который по умолчанию выполняется под учетной записью компьютера. Делегация Kerberos в этом случае не нужна:

- name: Custom modules loaded into module directory
win_dsc:
resource_name: File
SourcePath: '\\share\dsc\modules'
DestinationPath: 'C:\Program Files\WindowsPowerShell\Modules'
Type: Directory
Recurse: true
Force: true
MatchSource: true

При этом нет противоречия в том, чтобы отказываться от DSC, но использовать его ресурсы, если они лучше решают задачу, чем модуль Ansible. Главная цель прекратить использовать DSC-конфигурации, потому что нас не устраивала именно экосистема DSC, а не сами ресурсы. Например, если нужно создать виртуальный свитч Hyper-V, то придется использовать ресурс DSC в Ansible пока нет средств по управлению конфигурацией Hyper-V.

Сетевой дисконнект

Некоторые задачи вызывают отключение сети (дисконнект) на конфигурируемых серверах. Например, создание виртуального свитча Hyper-V из примера выше:

- name: External switch present
win_dsc:
resource_name: xVMSwitch
Ensure: 'Present'
Name: 'Virtual Network'
Type: 'External'
NetAdapterName: 'TEAM_LAN'
AllowManagementOS: True

Проблема в том, что в DSC такой вызов работает, а в Ansible завершается с ошибкой, так как управляемый хост дисконнектнул. Это происходит потому, что Windows всегда дисконнектит при создании виртуального экстернал-свитча. Решение добавить к таску аргумент async:

async: 10

Так Ansible отправляет таск на хост, ждет заданное время и только потом запрашивает состояние.

Дрифт инфраструктуры

Когда мы стали переносить код, обнаружили дрифт конфигураций. Это фактические различия между тем, что описано в коде, и реальной конфигурацией сервера или ПО. Причина в том, что в некоторых случаях DSC выполнял только часть работы, а остальное делали либо скриптами, либо вручную по инструкции.

Чтобы облегчить работу с IaC, мы собрали все скрипты и документы и сделали единые однозначные инструкции. Кроме этого, организовали процесс так, чтобы никто не внес случайные изменения в Ansible. Мы храним весь инфраструктурный код в GitHub, а задачи инженерам ставим через GitHub Projects, поэтому у нас есть возможность связывать изменения инфраструктурного кода (pull requests) с задачами. Так мы можем посмотреть изменения по каждой выполненной задаче. Если у задачи не будет изменений, то её не примут и вернут на доработку.

Баги сбора фактов

В отличие от DSC, Ansible при запуске собирает факты об управляемых хостах, чтобы у разработчика была возможность определить поведение тасков в зависимости от состояния хоста. При сборе фактов с Windows-хостов Ansible может выдавать ошибку, из-за некорректного кода модуля. Чтобы её исправить, нужно подключить коллекцию ansible.windows.

[WARNING]: Error when collecting bios facts: New-Object : Exception calling ".ctor" with "0" argument(s): "Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index" At line:2
char:21 + ... $bios = New-Object -TypeName


Пайплайн для Ansible перед запуском каждого плейбука проверяет наличие файлов requirements.yml со списком необходимых ролей и коллекций, а затем устанавливает их. Туда мы и добавили коллекцию ansible.windows.

Коллекции это новый концепт развития Ansible. Если раньше в Galaxy распространялись только роли, то теперь там можно найти подборки различных плагинов и модулей, плейбуков и ролей.

Тесты

Прежде чем передать IaC-инструментарий разработчикам, мы хотели быть уверенными, что Ansible-код будет надежным и ничего не сломает. В случае с DSC никаких специальных тестов не было, хотя существует специальный фреймворк для этой задачи. Конфигурации обычно валидировались на стейджинг-серверах, поломка которых не приводила к дефектам.

Для тестирования Ansible обычно используют инструмент molecule как обертку для запуска тестов. Это удобный инструмент для Linux-ролей, но в случае с Windows есть проблема. Раньше molecule умела поднимать инфраструктуру сама, но сейчас разработчики убрали такую возможность. Теперь инфраструктура поднимается либо с помощью molecule в Docker, либо вне molecule. Протестировать Windows-роли в Docker чаще всего невозможно: Hyper-V и большинство других Windows-фич в Docker-контейнере не установятся. Придется разворачивать инфраструктуру под тесты вне molecule и использовать delegated driver в molecule.

Эту задачу мы еще не решили, но нашли инструменты, которые обнаружат самые очевидные ошибки:

Как устроена работа с Ansible

После того как мы внедрили Ansible и преодолели все сложности, сформировался процесс действий инженеров и автоматических запусков:

1. Инженер пишет код роли и тесты к ней, если это роль для Linux-серверов. Как только инженер решит, что роль готова, он делает pull request в отдельный бранч в GitHub-репозитории, созданном специально для роли.
2. При создании pull request автоматически запускается воркфлоу GitHub Actions, который выполняет синтаксическую проверку и линтинг роли. Если это Linux-роль, то запускаются еще и тесты. Инженер проверяет, что всё хорошо, и при необходимости исправляет.
3. Другой инженер делает ревью кода из pull request. После того как автор роли исправляет все замечания, код вливается в мастер-бранч, а версия роли автоматически повышается.
4. Теперь нужно развернуть новую версию роли. Версии перечислены в специальных файлах requirements.yml, которые лежат в GitHub-репозитории с плейбуками. Для каждого плейбука отдельный такой файл. Автор роли изменяет версию в таком файле. Если нужно развернуть роль на серверы, которых нет в инвентаризации Ansible, автор дополняет инвентаризацию. Потом автор снова создает pull request, но уже в репозиторий с плейбуками.
5. После подтверждения pull request снова запускается GitHub Actions, который создает новый релиз в Octopus Deploy. Роль готова к развертыванию.
6. Инженер заходит в Octopus Deploy и запускает развертывание. Процесс развертывания позволяет инженеру ограничить теги и хосты, а также переопределить переменные аналогично опциям команды ansible-playbook: --tags, --limit и --extra-vars.
7. Процесс развертывания сначала запускает режим проверки, который показывает, какие изменения будут сделаны. Инженер оценивает результат проверки и либо подтверждает развертывание кода на целевую инфраструктуру, либо сначала устраняет обнаруженные недостатки.

Организация работы с Ansible

Что выбрать: DSC или Ansible

Евгений Берендяев, SRE-инженер

Mindbox два миллиона строк кода b2b бизнес-логики под нагрузкой. Наши продукты: CDP, программа лояльности, персонализация сайта, транзакционные и массовые рассылки критичные по надежности и скорости работы элементы инфраструктуры бизнеса.

Тринадцать лет мы ищем способы масштабировать разработку, чтобы при росте всё работало надежно и, при этом, быстро выпускались новые фичи. Когда-то важным казалось легко переименовывать колонки в БД. Теперь пришлось менять всю архитектуру на ходу.

Это третий ежегодный пост про разработку по итогам черной пятницы недели максимальной нагрузки. Почему наконец думаем, что мы молодцы; что для этого сделали; почему столкнулись с трудностями и что планируем делать дальше.

Резюме: два года работали не зря

Пятый год подряд нагрузка на Mindbox примерно удваивается ежегодно. В ноябре 2020 мы обработали 8,75 млрд запросов к API, против 4,48 млрд годом ранее. Пик 400 тысяч запросов в минуту. Отправили 1,64 млрд писем и 440 млн мобильных пушей. Год назад писем было 1,1 млрд, а пушей почти не было.

Динамика количества рассылок в неделю черной пятницы:



По нашим данным, это сравнимый с hh.ru уровень нагрузки по запросам к API, по нагрузке на базы данных с Avito. Около трети от Яндекс-такси по запросам в минуту.

В 2018 и 2019 годах мы справлялись с этим плохо: клиенты страдали от отказов. По итогам 2018 я надеялся на быстрые улучшения и ожидал бизнес-роадмэп, выполнить который до сих пор удалось только на половину. В 2019 про роадмэп я решил умолчать, так как надежность ухудшилась, отказы начались уже в сентябре, а в черную пятницу повторились, несмотря на большой объем проделанной работы.

Сегодня можно делать вывод: справляться с ростом мы научились. Черная пятница в 2020 прошла без инцидентов, затронувших более одного клиента. Было два краткосрочных частичных отказа по вине внешней инфраструктуры, не нарушивших SLA. К сожалению, жалобы от нескольких самых крупных клиентов были, но это понятные нам единичные истории, над которыми мы работаем.

Более того, данные и субъективные отзывы пользователей показывают долгосрочный тренд увеличения качества разработки. Уменьшается количество дефектов критических ошибок, отказов и случаев неудовлетворительной производительности.

На графике нарушения внутреннего SLA (более строгого, чем внешнего), которое в этом году мы дополнительно сделали еще более строгим:


Количество нарушений внутреннего SLA у среднего клиента

Нам удалось за два года полностью переизобрести разработку, продолжая расти средним темпом 40% выручки в год (в 2019 431 млн, в 2020 618 млн) и выпуская новые фичи. Ощущения примерно, как менять двигатель у машины на полном ходу.

Что сделали за два года:
Попробовали централизованное управление разработкой (LESS) и отказались от него, выработав децентрализованные процессы, в том числе управления надежностью.
Выделили до 50% ресурса разработки на улучшение качества, сформировали две (из восьми) выделенные инфраструктурные команды.
Удвоили штат SRE. Теперь у нас семь SRE и круглосуточные дежурства.
Сделали успешную школу разработчиков, закрывающую половину потребности в найме, научились нанимать сеньоров и лидов.
Автоматизировали SLA и сбор других метрик разработки.
Мигрировали критичные элементы инфраструктуры в Яндекс-облако, полностью поменяв технологии разработки.

Это далеко не всё из запланированного. Продолжаем увеличивать объем выделенных на качество ресурсов. Ожидаем дальнейшего увеличения качества и ускорения выпуска новых функций в 2021 году и далее.

Кстати, мы регулярно пишем об обновлениях в продукте и ведем статус-страницу с историей инцидентов.

Истоки трудностей: 20082018

Mindbox продукт со сложной бизнес-логикой, с 2008 года мы развивались как сервис для крупного бизнеса, с долей расходов на разработку более 30%. С точки зрения архитектуры это было традиционное монолитное приложение, но очень качественное: каждый день мы выпускали и до сих пор выпускам несколько обновлений монолита.

В 2014 рынок заставил нас повернуть в сторону более массового сегмента, в том числе е-commerce и retail. Это потребовало вложений в клиентский сервис, продажи и маркетинг.

Компания никогда не привлекала внешних инвестиций, всегда развивалась на свою прибыль. Вдобавок в 2017 году, через полгода после того как я стал CEO, мы столкнулись с нехваткой денег, я испугался и избыточно нарастил рентабельность. Всё это привело к сокращению расходов на разработку до 24% от выручки в 20182019 годах.

Одновременно с этим нужно было выпустить множество нужных новым клиентам функций при быстром росте нагрузки и количества клиентов. Мы справились за счет задела исходного продукта и архитектуры, а также децентрализации формирования автономных продуктовых команд.

К сожалению, техническая экспертиза таких команд не поспела за ростом компании, что дополнительно усугубилось пределами возможного в монолитной архитектуре. Технический долг копился, набор используемых технологий устаревал, зарплаты были ниже рынка. Нанимать инженеров становилось всё сложнее, несмотря на интересные задачи и уникальную культуру компании. К 2018 количество клиентов выросло в 10 раз, успех продукта стал очевиден, как и проблемы в надежности и разработке в целом.

Какие меры мы приняли

Процессы и ресурсы

Первой гипотезой была централизация: в 2019 внедрили LESS это когда над одним проектом работает одновременно несколько команд. Начали совместно проектировать эпики и работать с надежностью, удалось увеличить предсказуемость и нащупать полезные практики проектирования. Однако по прошествии года стала очевидна неэффективность процесса: демотивация и снижение ответственности команд из-за отсутствия чувства своих фичей, большие затраты на управление, заниматься которым никому не нравилось.

За год совместного проектирования появилось видение децентрализованной архитектуры, которая позволила бы каждой команде отвечать за изолированные микросервисы, при этом продолжая поставлять единый продукт клиентам. Вместе с видением возникли бэклоги задач и стало понятно, что над инфраструктурой необходимо работать выделенными специалистами, не прерывая её бизнес-роадмэпом.

Договорились выделить 30% ресурса на технический долг на постоянной основе. Была сформирована первая инфраструктурная команда, начали снова выделять автономные команды. При этом сохранили ряд централизованных процессов совместной работы, прежде всего нацеленных на поддержание качества:
проектирования,
анализа дефектов,
моделирования нагрузки на железо,
демо и синхронизационных статусов.

Пришли к ответственности архитекторов и команд за метрики надежности и прогноз стоимости серверов. Дополнительно выделили 30% в каждой команде на техдолг и баги, при ожидании непрерывности поставки бизнеса.

В 2020 процессы устоялись: сформировали вторую инфраструктурную команду, наладилась поставка. Доля ресурсов на бизнес-задачи стала медленно расти с нижней точки около 50%, а доля багов стала уменьшаться:


Распределение ресурсов разработки по задачам. График не очень информативен, так как надежную метрику наладили относительно недавно, но подкрепляется впечатлениями с мест

За это время научились нанимать и онбордить SRE, отделили их от DevOps и офисного IT, сформировали процессы дежурства и описали роль.

Дефицит инженеров удалось снизить двумя способами:
Создали школу разработки, выпускающую 8-12 junior-разработчиков в год. Это разработчики, имеющие опыт с нашим стэком, в способностях которых мы уверены. На сегодня в школе постоянно учатся 2 команды по 4 стажера.
Планомерно повышали ФОТ разработки, благо бизнес-результаты позволили. Средняя зарплата в разработке выросла со 120 тысяч рублей в 2015, до 170+ на конец 2020 и продолжает расти. Это позволило нанять несколько новых сильных сеньоров и техлидов. Доля расходов на разработку поднялась до 28%, а количество людей выросло с 27 до 64.

Метрики, метрики и автоматические метрики

В нашей культуре принято управлять на основе данных, а не личного мнения. Эффективные метрики, пожалуй, один из сложных вопросов, на который современные методологии управления разработкой прямого ответа не дают.

Мы начали с автоматизации четырех метрик из книги Accelerate и ускорения конвейера поставки. Это не дало немедленных очевидных эффектов. Зато обмен опытом с hh.ru и Яндекс-облаком привел нас к автоматизации метрики нарушения SLA и автоматическому заведению дефектов. Тут мы ясно ощутили пользу и связь с прикладываемыми усилиями. График этой метрики с трендом в начале поста.

Нескромно, но, думаю, мы одна из немногих в мире компаний, у которой есть API для клиентов, позволяющий получать метрику доступности компонентов платформы в реальном времени.

Описанная выше метрика доли багов и техдолга в команде тоже кажется полезной. Дополнительно считаем, как команды выполняют обещания, данные на спринт, а разработчики соблюдают сроки ежедневных и еженедельных задач.

Наконец, анонимные квартальные опросы (тексты с тех пор улучшились, но суть опроса не поменялась) и высокая оценка на Хабр-карьере показывают уменьшение несчастья разработки. Это касается оценки своего дохода относительно рынка, переработок и eNPS (данные пока только за два квартала).

Опрос о доходах разработчиков:



Опрос о переработках разработчиков:



eNPS разработчиков:

По шкале от 1 до 10 насколько вероятно, что порекомендуешь Mindbox как место работы?

Наконец, но не в последнюю очередь техника

Всё это позволило организовать переписывание монолитного продукта более 2 млн строк кода на IIS + ASP.NET + NLB / Windows Service / MS SQL одновременно по всем направлениям:

Микросервисный API и бэкенд, когда один запрос клиента к API Gateway прозрачно обрабатывается несколькими микросервисами, в том числе синхронные запросы (saga pattern).
Микрофронтенд, где разделы интерфейса отделенные от бэкенда SPA-приложения, способные размещаться в собственных репозиториях, со своим конвейером выкладки.
Перевод мультитенантных микросервисов с MS SQL на распределенные масштабируемые хранилища: Cassandra, Сlickhouse. Kafka вместо RabbitMQ.
Перевод приложения на .NET Core, linux и частичный переезд в Managed Kubernetes Яндекс-облака. Тут же внедрение современных SRE и DevOps технологий: OctopusDeploy + Helm, Prometheus, Grafana, Graylog + Sentry, Amixr.IO.

Возможно, мы один из самых нагруженных клиентов Яндекс-облака, поэтому о нашем внедрении и совместном с Яндексом преодолении трудностей CTO Никита Прудников рассказал на Yandex Scale 2020.

В нашей статье о черной пятнице можно почитать об основных применяемых нами подходах к масштабированию на примере компонента рассылок, который не сломался уже в прошлом году и не сломался в этом.

Дальнейшие планы развития

Несмотря на достигнутые результаты, должен сказать, что сделано меньше половины из запланированного. Впереди:
Продолжение повышения доходов разработчиков и найма лучших сеньоров и техлидов.
Третья команда школы разработчиков, позволяющая выпускать до 12 разработчиков в год.
Продолжение перевода приложения на .NET, k8s и Яндекс-облако, автомасштабирование, blue-green выкладка с моментальными rollback.
Движение к автоматическому заведению инцидентов на статус-странице, избавление от ложных срабатываний SLA.
Переход на .NET 5, EF.Core и PostgreSQL (а разработчиков на новые макбуки)&
Выделение еще нескольких крупномасштабных кусков из монолита.

Призываю мотивированных расти .NET-разработчиков, техлидов и SRE-специалистов откликаться на наши на наши вакансии на hh.ru. Будет интересно, можно приобрести уникальный на рынке опыт и делать штуки.

Роадмэп платформы в 2021 году

Мы ощутили твердый фундамент под ногами, который позволяет надеяться, что мы снова можем выполнять обещания по бизнес-роадмэпу. Процессы децентрализованного планирования на год пробуем первый раз, но опрометчиво позволю себе сформировать публичные ожидания.

В этом году добавим в платформе:
Конструктор сценариев.
Хранение анонимных заказов и отчетность по ним.
Больше быстрых отчетов в интерфейсе (как в нашем курсе).
Интеграцию с BI.
Новый модуль мобильных пушей, в том числе. новый SDK.
Возможность быстро удалять любые сущности с учетом зависимостей друг от друга.
Больше ML-алгоритмов и множество улучшений качества существующих.
Больше страниц в новом дизайне с улучшенной отзывчивостью интерфейса.
Упрощенную настройку стандартных интеграций и механик.

Планы на 2022 более грандиозные, но о них надеюсь написать через год, если оптимизм окажется оправдан.

Спасибо

Как и клиентские истории успеха, эта заслуга конкретных людей, которым выражаю благодарность:

Никите Прудникову, CTO, за видение, системность и планомерное дожимание.

Роману Ивонину, ведущему архитектору, за терпение, построение команд, широкую ответственность, неформальное лидерство и бессонные ночи.

Игорю Кудрину, CIO, за фундамент SRE-экспертизы, видение и спасение всего, когда никто не знает как.

Ростиславу, Леониду, Дмитрию, Мите, Илье, двум Артёмам, Алексею, Сергею, Николаю, Ивану, Славе, Жене и другим неравнодушным разработчикам, продуктам, техлидам и SRE, сделавшим всё это реальностью. Простите, если кого-то не упомянул.

Отдельное спасибо клиентам, которые терпели, не смотря на то что мы подводили, и дали возможность исправиться. Приложим все усилия, чтобы дальше становилось только лучше.

Если бизнес идет вверх, тозапросы инагрузка наразработку увеличиваются вразы. Рано или поздно каждый управленец сталкивается свыбором издвух крайностей: встать насторону бизнеса, двигать продукт идемотивировать разработчиков бесконечным техдолгом или дать свободу разработке ипотерять контроль над задачами бизнеса.

Mindbox 15лет развивает B2B-продукт ивырос с3до70человек вразработке. Мытестировали разные подходы кмасштабированию иготовы поделиться опытом, чтобы вам непришлось наступать натеже грабли. Ниже расскажу, как попробовали полную автономию команд ицентрализацию, роняли надежность, демотивировали команды, как врезультате сэтим справились ивыработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:

Надежность как ядро разработки

Чтобы оценить, окаких масштабах разработки инагрузке пойдет речь, расскажу оразмере компании.

ВMindbox одна изсамых нагруженных разработок вРоссии, нопри этом она сохраняет высокую надежность. Когда покупатель пробивает чек накассе вБургер Кинге или аптеке Ригла, транзакция идет кнам. За200 миллисекунд мырассчитываем суммы иотвечаем кассе. Если сервис упал, томного людей повсей стране 24/7 становятся несчастны.

Запоследние 34 года бизнес растет по4050% вгод инагрузка удваивается ежегодно. Внешне всё отлично, ноуMindbox был длинный период становления, который влиял намасштабирование разработки.

Масштаб бизнеса и разработки

Эволюция разработки

Как работает автономия ицентрализация разработки

Проблема масштабирования разработки сводится кпоиску баланса между автономией ицентрализацией. Есть две организационные крайности:

1. Автономия. Вомногих компаниях победили автономные инженеры инет никаких сроков. Разработка постоянно закрывает секретный техдолг, абизнес непонимает, как решать крупные задачи. Это заканчивается революцией: бизнес теряет терпение ивносит радикальные изменения впроцессы.
2. Централизация. Другая крайность когда побеждает бизнес. Дедлайны спускаются наразработку сверху, задачи бизнеса решаются, нокопится техдолг. Потом процессы опять замедляются иистория заканчивается революцией: предлагают переписать код снуля или продать компанию.

Микросервис имонолит. Две архитектурные крайности микросервис имонолит напрямую несвязаны сописанными типами управления, нопохожи поэффекту. Микросервисы работают быстро, ночем ихбольше, тем больше инфраструктурных задач реализуются несколько раз вместо одного. Вмонолите, наоборот, сначала всё эффективно, нопотом замедляется из-за множества зависимостей.

Мынашли баланс между автономией ицентрализацией: дали техническую автономию продуктовым командам ввопросах сервисов ицентрализовали управление процессами, которые относятся ковсем командам. Ниже расскажем, что это означает икак мыкэтому пришли.

Как внедрили автономию

С2007 по2013 год было мало клиентов ибизнес рос медленно, потому что писали большой исложный продукт. При этом управление разработкой было простым: один главный бизнес-эксперт иглавный архитектор это я и34команды. Делал статусы раз внеделю, потом раз вдве недели ходил покомандам эффективно илегко.

Дали автономию командам. Постепенно бизнес стал прибавлять по4050% вгод, поэтому нужно было запускать больше продуктов ипродвигаться быстрее. Втоже время мыначали строить бирюзовую культуру, прочитали книгу Лалу ирешили, что нужны автономные продуктовые команды сменеджерами продуктов. Иэто заработало запустили новые продукты.

Бирюзовая компания вРоссии: открытые зарплаты, самоуправление, прозрачность иошибки
Фредерик Лалу: Открывая организации будущего

Децентрализовали инфраструктуру. Мырешили, что раз такой подход работает, надо его распространять дальше. Была команда супергероев топовые инженеры, которые поддерживали продакшен иработали над сложными задачами. Чтобы разработка стала ещё быстрее, выделили каждой команде своего эксперта поинфраструктуре, ацентрализованную инфраструктурную команду разделили надве продуктовые. Иэто тоже сработало, разработка продуктов ускорилась.

Уронили надежность. Потом появились нюансы. Большинство наших клиентов изe-commerce, поэтому проводят черную пятницу большую распродажу вконце года, когда унагрузки пиковое значение. Кроме этого, нагрузка ещё иудваивалась каждый год. Втакую черную пятницу сервис упал.

Всё лежит ивсё плохо, чрезвычайная ситуация. Провели спринт надежности иполностью остановили roadmap, чтобы вернуть сервис кжизни. Вкнигах осамоуправлении это называют остановить конвейер, когда все команды бросаются чинить надежность. Имыостановили, ноникто непобежал чинить, потому что половина людей непонимала, вчем проблема икуда бежать. Это было первое наблюдение, апотом надежность вцелом стала резко ухудшаться.

Как внедрили централизацию

Централизовали управление. Прочитали книгу оLeSS (Large Scale Scrum), сходили натренинг ирешили централизовать разработку: внедрить общий roadmap, единое управление иразгрумить эпик надежности.

Врезультате немного улучшили надежность иroadmap начал продвигаться. Мыразделили его набольшие куски, установили очередность продуктов иработали над ними силами всех шести команд.

Внедрили LeSS ироль CTO. Надежность разово починили, ноостался монолит на2миллиона строк кода. Несмотря наточто мыцентрализованно внедрили roadmap ивкаждой команде работали эксперты поинфраструктуре, техдолг ипроблема корневой надежности децентрализованно нерешались.

Так мысоздали роль CTO (chief technical officer), хотя доэтого небыло менеджмента, отвели30% ресурса натехдолг ивнедрили LeSS. Это значит, что70% разработчиков занимались roadmap бизнеса, а30% техническим roadmap, который определяет CTO. Врезультате техдолг начал сокращаться, имыувидели положительные изменения.

LeSS Scrum набольших масштабах

Создали ритуал надежности. CTO предложил, чтобы команды сами приходили ирассказывали, что ипочему они сделали или планируют сделать для надежности. Так появился ритуал надежности. Архитекторы совсех команд, CTO ипродуктовые эксперты собирались раз вдве недели или раз вмесяц иразбирали, какие выявились дефекты икритические баги, вчем была причина ичто нужно чинить наглобальном уровне, ачто решать локально. Так мыввели разумное регулирование идецентрализация заработала.

Демотивировали инженеров именеджеров попродукту. Следом случилась ещё одна черная пятница, исервис снова лег. Это было грустно, хотя мыуже видели, что есть положительные изменения. Ноэто было неглавным.

Главное, что год мыпрожили врежиме LeSS изаметили негативные эффекты для компании. Инженеры именеджеры попродукту были демотивированы. Уинженеров небыло домена ичувства собственности, как увавтономных команд: три месяца они работали над одним продуктом, потом три месяца над другим. Менеджеры попродукту загрустили, потому что roadmap планируется централизованно иtime tomarket стал огромным. Нельзя было взять ивнедрить небольшую доработку для клиента, потому что roadmap управляют централизованно.

Как нашли баланс между автономией ицентрализацией

Вернули командам автономию. Мыувидели, что регулируемая децентрализация работает для повышения надежности, поэтому решили вернуться кистокам, свернуть LeSS иразделить продуктовые команды.

Вернули команду инфраструктурной платформы. Фактически инфраструктура это тоже внутренний продукт, аCTO выполняет роль менеджера попродукту, поэтому выделили отдельную команду под инфраструктуру.

Сточки зрения бирюзы инфраструктурная команда казалась неправильным шагом, новделе это показало себя хорошо, итакая команда мотивировала всех остальных. Сначала мыбоялись, что интересные технические задачи уйдут винфраструктурную команду. Насамом деле выделили для этого отдельных экспертов иотдали задачи, которыми нехотели заниматься разработчики издругих команд.

Оставили30% ресурса команды налокальный техдолг. Мыдоговорились одвухуровневом разделении. Наверхнем уровне30% всего ресурса разработки отдали CTO наинфраструктурную команду итехнический roadmap. Ещё30% отдали натехдолг, который приоритезирует команда. Фактически смомента, когда начались проблемы снадежностью имасштабированием, почти50% всего ресурса это технические задачи.

Техдолг ~30% платформы и 30% команды

около 50% в целом



Внедрили кросс-командный рефайнмент. Это практика изLeSS, которую мымодифицировали. Прежде чем команда начинает работу над каким-то автономным эпиком, она готовит описание ивыносит наобсуждение сдругими командами. Такой подход помогает выявить риски ипонять, как изменения касаются других команд икакие зависимости вмонолите неучли.

Изначально ошибка была втом, что мывыделили автономных менеджеров попродукту, которые создавали интересные фичи, нопри этом небыли экспертами понадежности иинфраструктуре вмонолите. Ито, что они делали, ломало другие фичи из-за чрезмерной централизации. Чтобы снять эти риски, мыоставили кросс-командный рефайнмент.


Из LeSS оставили кросс-командный рефайнмент, чтобы снять риск монолита и управлять roadmap

Ввели автоматический контроль надежности. Чтобы усилить надежность, мыпосоветовались сразными компаниями исделали автоматическую метрику. Раньше клиенты жаловались накритические баги, менеджеры сообщали обэтом разработке имыиханализировали. Атеперь мысоздали автоматические уведомления, который приходят, если нарушаются определенные метрики. Иэто помогло улучшить надежность, потому что навсех статусах мыстали обсуждать формальные вопросы: нарушается SLA или нет.

Несмотря наточто впрошлый раз мыупали вчерную пятницу, было ощущение, что платформа стала надежнее имыдвижемся вверном направлении. Новая метрика доказала наши наблюдения надежность компании действительно росла.

Нарушения SLA среднего клиента вмесяц надежность повышается

Починили надежность. Следующую черную пятницу мыпережили нормально. Это стало доказательством того, что процесс работает иесть положительный эффект для бизнеса.

Создали роль Scrum-мастера. После того как разобрались срисками вдецентрализованном roadmap, справились стехдолгом инадежностью, решили повышать эффективность разработки. Для этого создали роль Scrum-мастера, который собирает весь опыт разработки (developer experience) изаносит вспециальную форму все препятствия ипричины, мешающие разработке. Потом поаналогии состатусами понадежности Scrum-мастера централизованно обсуждают сCTO задачи замесяц, приоритезируют ихичасть добавляют втехдолг.

Создали круги управления. Чтобы комплексно управлять общими аспектами разработки, мыорганизовали виртуальную команду, или круг управления, представители которого сидят вразных командах. Уэтого круга есть набор ритуалов, которые собраны надоске вTrello: встречи побюджету, демонстрации продукта или найму. Такое кросс-командное общение помогает сфокусироваться накаждом процессе инатом, как его улучшить вовсех командах сразу.

Виртуальная команда (круг) управления

Ритуалы управления

Круг управления помогает аккумулировать кросс-командные аспекты: надежность, стоимость железа, найм, developer experience. Для этого проводятся встречи ритуалы управления


Определили метрики разработки. Пока мымасштабировали разработку, нас волновал один вопрос: какие метрики позволяют оценить разработку ичто нужно оптимизировать. Это было неочевидно.

Мызнали, что скорость иroadmap нельзя измерять, потому что есть проблемы стехдолгом иэто только демотивирует разработчиков. Науровне стратегии разработки мысформулировали, что цель разработки оптимизировать непрерывный запуск продуктов (time tomarket) врамках ограничений надежности, стоимости железа ибез увеличения технического долга. Ировно такиеже ожидания сформировали для команды. Команда должна непрерывно поставлять фичи, увеличивать time tomarket, нопри этом поддерживать определенные обязательства понадежности, SLA истоимости.

Когда мысформулировали ожидания, стало легче оценивать результаты разработки. Исходя изэтого мыстроим метрики ипродолжаем оптимизировать разработку.

Показатель эффективности

врамках SLA, стоимости железа ибез увеличения техдолга

Какую выработали систему масштабирования разработки

Продуктовые команды. Еслибы мысейчас строили разработку снуля, топоумолчанию выделили децентрализованные продуктовые команды. Желательно, чтобы укаждой был свой сервис инебыло монолита нанесколько команд. Наша реальная ситуация оказалась сложнее: есть монолит, поэтому надежность зависит отнего, есть централизованный найм ицентрализованная стоимость облачного железа.

Разумное регулирование общего. Как ядро оставили общие задачи, над которыми должны работать централизованно: roadmap монолита, надежность иинфраструктура, стоимость железа иdeveloper experience. Если нет общих знаний отом, как создаются базовые вещи, топеремещение разработчиков между командами будет затруднено, код будет дублироваться иесть риск потерять эффект масштабной разработки, когда каждая команда существует изолированно отвсех.