Всем привет. Сегодня я хочу рассказать о том, как мы прошли наш путь от хаоса к нашим Paas внутри нашего внутреннего облака. Меня зовут Михаил Марченко, я руководитель центра компетенций, сопровождения и построения процессов разработки. Это наше подразделение, где мы сосредотачиваем экспертизу DevOps. В девопсе я уже семь лет, из них последние три года в билайне.
В большой бренд билайна входят достаточно большое число юрлиц, такие как Вымпелком, Датафорт, который реализует публичное облако билайна, и другие. И мы поняли, что IT у нас абсолютно распределённая и существует во всех юрлицах, во всех подразделениях и во всех командах, которые внутри этих юридических лиц. И внутри Вымпелкома есть отдельное подразделение, которое возглавляю я, в котором сосредоточена экспертиза DevOps, мы его называем "DevOps Governance".
Делим мы его на две части.
Это группа DevOps в команде, которые отвечают за CI/CD и troubleshooting приложений продуктовых команд. Также они могут выступать провиженерами идей DevOps.
DevOps-инфраструктуры в свою очередь создают инфраструктуру разработки, поддерживают платформу контейнеризации Kubernetes, помогают реализовывать те сервисы, которых не хватает, например, Sentry, для того, чтобы
мы понимали, какие ошибки возникают у наших пользователей. В первую очередь — на их устройствах, которые видят они и получают самый-самый негатив от того, что у нас может что -то идти не так. И это подразделение создает те самые Paas-сервисы в нашем приватном облаке. Мы цифровые не только снаружи, но и цифровые внутри. Мы ценим, как нашего клиента, который является клиентом нашего бренда билайна, но мы сосредоточены и на том, чтобы удовлетворить внутреннего клиента — нашего разработчика.
Показательный пример — все энтерпрайзы уже давно сосредоточились на том, чтобы хранить свой код централизованно. Мы пошли таким же путем. Но мы поменяли подход.
Мы спросили те продуктовые команды, у которых уже были свои гитлабы — а что вам нужно, чтобы вы максимально эффективно потребляли наш централизованный гитлаб? Что необходимо, чтобы вы к нам пришли сами? Не мы вас к себе затянули, а сами пришли.
И зачастую нам продуктовые команды говорили о тех болях, которые у них были в рамках эксплуатации свои гитлабов, например, такие, как хотим multiple approvals. Мы сейчас как раз в процессе реализации такой фичи.
Расскажу про весь путь, как мы прошли, и нельзя рассказать про путь, не рассказав о том, что было в самом начале.
Когда в 20 -м году билайн принял решение стать высокоинженерной компании, у нас виртуальные машины выдавались порядка 90 дней в среднем. Бывали случаи, когда и по полгода люди проталкивали свою бумажечку RFC, чтобы получить виртуальную машину. Количество IT-персонала было порядка 700 человек, зачастую это были именно администраторы приложений, эксплуатация, но разработки практически не было. Каких-то тестовых средств тоже не было, все практически для нас реализовывали вендоры.
Поэтому у нас очень большие проблемы были, когда случались какие-то инциденты на нашей инфраструктуре, мы не понимали, из-за чего это происходит, как это чинить, и приняли решение сделать свою собственную компанию, сосредоточенную на создании IT-решений внутри.
В 21-м году после принятия этого решения у нас резко пошло число разработчиков вверх, им потребовалось большое число новых виртуальных серверов, а время получения виртуальных машин в 90 дней просто не могло никак соответствовать каким-то вменяемым показателям для того, чтобы максимально эффективно развивать наш сервис.
В 21-м году мы автоматизировали выдачу куберов для того, чтобы продуктовые команды хоть где -то могли показывать свои наработки. В 22-м году мы поняли, что одного кубера нам недостаточно. Мы хотим выдавать базы данных, мы хотим делать очереди, которые очень сильно завязаны на диск, а в кубере, как мы знаем, не очень хорошо в то время жили все Stateful Services. Поэтому мы сосредоточились на том, чтобы автоматизировать выдачу виртуальных машин и мы смогли автоматизировать именно ручные действия в тот момент. По показателям пошли дальше и решили, что нам необходимо еще все больше улучшать, все должно быть сильно лучше.
А разработчикам на самом деле не нужны какие-либо виртуальные машины, им нужны конечные сервисы. И мы сосредоточились на создании своего клауда, где начали выдавать Paas-сервисы. И на текущий момент мы выдаем виртуальные машины и готовые сервисы примерно за 7 минут, и хотим увеличивать количество Paas-сервисов,чтобы пользователь не хотел заказывать для себя какие-либо виртуальные машины, чтобы все ему нравилось максимально.
Что же именно мы сделали в 2021 году?
Итак, мы хотим начать выдавать как-либо платформу контейнеризации для разработчиков. Для того чтобы это реализовать, нам необходимо хотя бы заказать пачку виртуальных машин, на которых мы раскатаем кубер и будем уже нарезать его максимально быстро.
Для этого надо RFC в билайне завести.
И для нас это было большой болью, потому что люди, которые создавали этот процесс, сделали его максимально гибким и с их точки зрения максимально удобным. Ты должен был просто описать то, что ты хочешь сделать, что тебе необходимо, какой необходим сервер. Это было одно большое поле, который читал человек и понимал, что необходимо сделать.
Все статусы, согласования проходили только через ручной досмотр человека, и это было просто безумно долго. Дополнительно к RFC именно на создание виртуальной машины необходимо было приложить вордовский документ, в котором надо было описать, что же тебе нужно конкретно, но необходимо было описать вообще всё — требования базы данных, хотя тебе и база данных может быть и не нужна на этом сервере.
В итоге это всё выливалось в максимально неудовлетворённый спрос. Слишком долго получалось, уже давно необходимо выходить в продуктив, а вы еще девовскую виртуальную машину не получили. Каждый пользователь ломал этот процесс дополнительно, поднимая переписку, создавая эскалации для того, чтобы ускорить конкретную свою RFC, и исполнители просто погибали в количестве этих эскалаций и самих запросах.
В среднем выдавалось порядка 50 виртуальных машин в месяц. Собственно говоря, на просторах нашей компании мы нашли пилот одного из подрядчика, OKD, который мы смогли выдавать еще более быстро, за счет того, что он уже был развернут и нам не надо было разворачивать кубер. Мы сосредоточились на том, что поднимали отдельно свой инстанс, а пока выдавали OKD разработчикам на текущий момент.
Он показал нам то, что слишком упрощая для разработчика вход в платформу разработки, такой удобной дашбордой и дополнительными сущностями, которые предоставляют OKD. Возможностью просто отдать ему репозиторий Гитлаба, и он тебе автоматом соберет и опубликует твоё приложение.
Это всё приводило к тому, что разработчики не понимали, как их приложение работает, а любые аварии ещё более непонятны были, чем ранее на физических серверах. Поэтому мы решили все-таки остаться на ванильном кубере. Мы также реализовали все, что есть в OKD, но дополнительно интегрировали со своими платформенными сервисами, таких как платформы наблюдаемости, куда мы собираем наши логи, метрики.
В 2022 году мы поняли, что компания все еще растет, мы выдаем вычислительные ресурсы, но мы не можем выдавать какие-то стейтфул сервисы в кубере, потому что скорости дисков в кубере нас не устраивали.
И мы пошли в автоматизацию рутинных действий наших инженеров. Но помимо этого мы должны были ещё ограничить пользователя и заставить его передавать чётко те параметры, которые необходимы для фактического исполнения. Наш потребитель хочет получить в первую очередь виртуальную машину быстро, уже с установленным ПО, таким как Postgres, Kafka, и всё это ПО и вся виртуальная машина должны удовлетворять нашим требованиям, которые выдвигают подразделения ИБ и внешние аудиты.
Мы начали спрашивать с пользователя только DNS-имя, которое необходимо для виртуальной машины, операционку, которая будет ближе к пользователю. Например, Rocky и Ubuntu, для того, чтобы покрыть и дев виртуальной машины и RPM.
Также мы спрашивали количество оперативной памяти, количество процессора, которое необходимо, диск для данных один и один диск для операционной системы.
Ещё спрашивали пользователю, необходим ли ему root на этот виртуальный сервер, или он хочет быть полностью комплайн с нашими требованиями, и тогда root оставался у отдела Unix-администрирования.
Но мы не смогли предложить на тот момент пользователю выбирать сеть или IP-адрес которой будет у этого сервера. Мы жестко ограничили тем, что там будет однозначно стоять наше ПО для комплаенса, такое как антивирус. Какие-то встроенные учетные записи однозначно будут для аудита и мониторинга.
Как это реализовывалось раньше?
Наш разработчик, DevOps Engineer, приходил в систему заявок, ремеди, оставлял какое-то нетипизированную заявку. Внутренний сотрудник, администратор, приходил в это ремеди, читал, что там от него хотят. Он делал всё сам руками, шёл в виртуализацию, в тот момент в VMware создавал виртуальную машину, создавал ей DNS-запись, записывал креденшнелы для соединения в VOLT, ставил сервер на мониторинг и сохранял запись о том, что он создал такой сервер в CMDB. Это наша система инвентаризации, где мы храним список серверов, к каким продуктам они привязаны. Так мы можем разбираться в наших инцидентах более оперативно, если человек, к которому попадает инцидент, не знает ничего о системе, в которой он пытается понять, что же произошло.
Что же мы сделали?
Мы сделали чуть другую заявку в нашу систему заявок ремеди. Она стала типизированной. Все так же мы создаем виртуальные машины в той же системе виртуализации. Все в тех же сервисах вносим данные, но теперь у нас Jenkins научился ходить в Remedy для того, чтобы переводить статусы заявок, чтобы читать параметры и передавать дальше.
Он дергал GitLab, который вносил все записи, создавал DNS, ставил на мониторинг, сохранял какие то креденшенелы для доступа к виртуальной машине, он же вызывал Terraform для доступа к Vmware для создания виртуальной машины и сверху дергали Ansible на отдельной виртуальной машине, просто для того, чтобы накатить туда Postgres, Redis, Kafka, Rabbit по желанию пользователя.
Это нам позволило удовлетворить те желания пользователя, но у нас все еще были проблемы.
Все эти RFC выполнялись порядка 30 минут. Многие системы были не готовы к тому, чтобы получать всю эту информацию из системы автоматизации. Изменение и настройка выданных серверов все еще производилось через отдельные RFC руками. Мы не смогли автоматизировать создание сразу группы серверов для того, чтобы как-либо накатывать на них те кластера, о которых была речь. Это все еще было ручными действиями — пользователь заводил заявку в нашей системе и не мог это автоматизировать никак через API. Хост с ANSIBLE у нас не масштабировался, это приводило к потому что мы максимум в один поток могли накатывать какое-либо ПО. И у нас часто собирались очереди на выдачу виртуальных машин. Это, кстати, почему в среднем 30 минут было.
Нам было чрезвычайно сложно разбирать проблемы, потому что мы не складировали информацию о том, как работает наш скрипт автоматизации в системе нашего мониторинга. Мы не уточняли у пользователя, в каком же регионе создать его сервер. Мы предвыбирали это за пользователя.
И даже уже с такими проблемами мы в декабре 2022 года достигли трёхкратного увеличения пропускной способности создания виртуальных машин. Почему же всё ещё руками создавались виртуальные машины? Потому что у нас нельзя было через нашу систему создать полностью любую виртуальную машину.
В 23-м году мы поняли, что за автоматизацией будущее, что пользователю необходима не просто виртуальная машина, а готовый сервис, и пользователь хочет получать его максимально быстро, удобно, через код.
То есть, мы от файла вордовского, который прикладывался к RFC на создание виртуальной машины, перешли к REST API, в котором необходимо указать IP-адрес, Affinity-группу, которая пробрасывалась из уже OpenStack. Количество виртуальных машин, размер этих виртуальных машин, Flavor, образ, предподготовленный нашими Unix-администраторами или администраторами Windows, какие -то дополнительные метаданные, имя виртуальной машины, регион, какие-то теги дополнительные для более удобной выборки ресурсов в нашем облаке, и информацию о дисках системно, мы, возможно, одном или нескольких дополнительных, где будут храниться данные.
За 23-й год мы поняли, что за облаком будущее, мы начали выдавать больше, чем в 10 раз виртуальных машин, чем мы выдавали руками. И это только за первую половину года — 8 месяцев, 3 квартала. Мало того, что мы начали быстро выдавать большое количество виртуальных машин, пользователь еще и начал возвращать эти виртуальные машины.
В четвертом квартале 23-го года было возвращено порядка 60% виртуальных машин, которые выданы.
Private Pass и зачем он нам нужен
Это безопасность, потому что он крутится в наших цодах, на наших серверах. Мы обеспечиваем полный жизненный цикл этого сервиса от момента получения, изменения, обновления до его удаления. Мы делаем его под себя, мы интегрируем его во все наши системы мониторинга, логирования. Мы сразу отдаём его на поддержку профильного подразделения, которое поддерживает его, полностью контролируем весь этот сервис, и он соответствует всем нашим комплаенсам, которые перед нами представлены, такие как, например, тайна связи.
Уже сейчас, с выдачей сервисов по модели PaaS, это порядка тридцати процентов от выданных виртуальных машин в последнем квартале прошлого года.
Как же мы это сделали
Раньше мы выдавали через Jenkins, GetLabsia, Terraform, Ansible. Теперь же мы точно так же записываем информацию в DNS, в CMDB, в Zabbix, который уже теперь не только Zabbix, но и другие системы нашей наблюдаемости. Записываем всякие данные Vault, точнее, уже берем их для того, чтобы иметь доступ ко всем виртуальным машинам из автоматизации.
Пользователь к нам может приходить через веб, API, Terraform Provider. Наш cloud vega, его кодовое название, получает эти данные и передает в провайдеры, которые записывают данные в DNS и создают виртуальные машины в OpenStack, уже не через Terraform, а напрямую, через его API.
Мы масштабировали наш хост с ансимблом за счет того, что заиспользовали AWX, который развернут в одном из наших кластеров кубера для того, чтобы иметь большую пропускную способность при создании виртуальных машин.
Что мы разворачиваем на виртуальные машины
Это все тот же PostgreSQL, отличительная особенностью, наверное, от просто Paas- сервисам, которые у нас всегда будут интегрированы с нашей единой системой авторизации, будут подключены к нашему мониторингу, к нашему логированию — тут мы дополнительно проверяем, что же у нас получилось, потому что наши DBA любят вносить изменения, в том числе в конфигурацию ядра. Мы дополнительно валидируем перезаписываемые параметры, это исторически сложившаяся история из-за того, что, когда ребята руками это создавали, слишком часто такое происходило. Теперь мы это тащим за собой как требования. Возможно, мы пересмотрим этот параметр.
При создании Kafka мы посмотрели, что у нас есть в компании. У нас был один большой продуктивный инстанс Kafka, представляемый нашими коллегами из подразделения DMP. Они отвечают за данные в нашей компании. Мы посмотрели, как у них реализована аутентификация, это был Kerberos, и мы поняли, что слишком много обратной связи от разработчиков, о том, что они не понимают, где возникают ошибки при аутентификации в Kafka. И это постоянно, каждая интеграция каждой продуктовый команды с Kafka DMP приводила к тому, что мы получали обратную связь о том, что слишком сложно, слишком долго.
Для себя мы выбрали oauth bearer, потому что это позволило нам централизованно управлять учетными записями. Мы подключили SSL, сделали для себя в облаке сервис ASMI, который выпускает приватные сертификаты нашего приватного центра сертификации. Также ставим это все на мониторинг. И в тех случаях, когда ПО не умеет аутентифицироваться в Kafka, мы изучили рынок и сделали вариант обхода через Kafka proxy. Официально его задокументировали и помогли нашим продуктовым командам, чтобы они могли использовать нашу Kafka, даже если они не умеют авторизовываться и не хотят изменять своё ПО. Например, Sentry не умеет авторизовываться в Kafka, и нам не надо дорабатывать Sentry, чтобы потреблять нашу же Kafka для него.
Сейчас мы активно заняты тем, что создаем Kubernetes в нашем облаке. Мы в первую очередь подключаем его к нашим системам инвентаризации, такие как CMDB, для того чтобы понимать, где у нас и что, дополнительно записываем информацию по потребляемым сетям в Kubernetes для того, чтобы не произошел случайно Overlap.
Выпускаем также сертификаты через наш внутренний центр сертификации. Автоматом создаем сетевые доступы для него и подключаем к логированию.
А теперь подробнее о том, какие инфраструктурные вещи мы накатываем в Kubernetes для того, чтобы он был комплайнс с нашими требованиями.
В первую очередь мы накатываем kyverno+policy для того, чтобы пользователи не могли, допустим, запуститься и -под рута и им выдавалась внятная ошибка. Мы подключаем автоматические cephfs и RBD для того, чтобы пользователи могли потреблять персистент-волюмы. Подключаем все поды к метрикам и логированию стандартными способами в единую платформу наблюдаемости.
Создаем общий ingress, чтобы продуктовые команды не задумывались о том, как им опубликовать свой сервис. Создаем дашборду для кубера, чтобы они могли визуально наблюдать, что у них там и в каком состоянии.
И подключаем vault webhook в реализации bank worlds для того, чтобы пользователи не-администраторы приложений не раскрывали у себя в консоли, какие секреты переданы приложением.
Плюс мы думаем над разработкой собственных дополнений, например, для выпуска собственных сертификатов на внутренних контурах.
В заключение хотелось бы сказать о том, что мы столкнулись с тем, что создавая кубер,, мы пытались для себя уложить вот это вот все в одну большую кучу, и мы поняли, что мы не понимаем, почему мы не можем создать этот сервис. Мы попытались схематично изобразить для себя, какие же вещи задействованы при создании одного или нескольких кластеров кубера.
У нас получилась вот такая вот хаотичная система, в которой мы просто запутались. Мы не понимали, что от чего зависит. Это не помогло нам никак. Мы пришли к тому, что создали ресурсно-сервисную модель для своего сервиса kubernetes и для всех остальных сервисов Pass, которые мы выдаём.
В первую очередь мы описали создание кластера и то, из чего он состоит. Например, виртуальные сервера, неймспейсы, которые в нём. Это ресурсы, которые мы по факту выдаём пользователю для конфигурирования. И после этого мы поняли, на чем нам необходимо сосредоточиться для того, чтобы идеально создать этот сервис. Например, что нам необходимо в нашем облаке создать secret storage и выкинуть hashcorp vault из выдаваемых сервисов для того, чтобы не только этот сервис создать, но и чтобы продуктовые команды могли более высококачественно получать секрет-менеджмент.
Из ключевых выводов
Мы выработали унифицированный подход к выдаче Paas-сервисов, который позволит создать по аналогии с уже имеющимися Paas-сервисами, такими как PostgreSQL, Kafka, Redis новые сервисы, которые необходимы нашим продуктовым командам, таких как Clickhouse, Rabbitmq.
Мы поняли, что, спрашивая пользователя, что ему необходимо для того, чтобы максимально удобно потреблять наши сервисы. Мы ценим нашего клиента и хотим, чтобы ему было максимально удобно, этот подход нам очень сильно понравился и мы будем продолжать применять его. Ресурсно-сервисная модель могла бы помочь нам еще в 2021 году, если бы мы начали сразу структурировать наши сервисы. Но мы дошли до этого только сейчас, рекомендую всем сначала проектировать сервисы, а потом их разрабатывать.
Мы хотим увеличить потребление наших Paas-сервисов с 30% до 80% через создание новых.