15 лет «Фланта»: переход от сервисной компании к продуктовой, покупка внешнего продукта, вера в Open Source

В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и активно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.

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

Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.

Первые 10 лет: как мы искали свою суперсилу

Первые 10 лет проскочим довольно быстро, хотя именно они заложили основу того «Фланта», который существует сегодня. Мы уже писали статью к своему десятилетию ^[1] — в ней все рассказано гораздо подробнее. Остановимся лишь на том, что особенно важно в контексте этого материала.

В 2008 году два друга — студенты одной кафедры и тезки — основали «Флант». Всё было пропитано духом авантюризма: любовь к Open Source, романтика, мечты о Linux на каждой рабочей станции. Кстати, именно тогда мы написали свой первый продукт — панель управления хостингом ^[2]. С самого начала мы то и дело писали небольшие утилиты для собственных нужд.

Дальше был долгий период становления бизнеса — причем без поддержки инвесторов и внешней помощи. Мы постепенно определялись с направлением работы: сначала обслуживали «всё под Linux», потом ограничились шестью направлениями, затем — четырьмя. Где-то тут появился и наш первый международный сертификат — мы стали авторизованным партнером Canonical.

В 2015 году мы признали, что основным фокусом все это время были веб-приложения, и «официально» отказались от остальных видов деятельности. А еще спустя небольшое время сузили услуги до обслуживания инфраструктуры на Kubernetes. Да, в Kubernetes и Docker мы поверили практически сразу после их появления, потому что до этого сами, как и некоторые другие игроки рынка, пытались сделать жизнь лучше похожими, но сделанными собственноручно решениями. В частности, у нас был внутренний проект по созданию инструментов для удобного управления изоляцией на базе Linux cgroups… 

Когда же мы сделали ставку на Kubernetes, это тоже потребовало определенных «обвязок» — ведь ни для кого не секрет, что технология молода, сложна и очень быстро меняется. Чтобы автоматизировать нетривиальные процессы установки и настройки инфраструктуры, реализации CI/CD, мы регулярно писали скрипты, операторы и какие-то мелкие утилитки для упрощения работы. В частности, было два интересных проекта: dapp (теперь уже werf) и shell-operator. 

werf мы начали разрабатывать в 2016 году — он помогал выстроить процессы CI/CD для приложений наших заказчиков быстро и эффективно, а также предлагал унифицированный подход для их дальнейшей поддержки и совершенствования. 

А shell-operator позволял писать операторы для K8s на Shell/Bash или Python. Оба инструмента мы в итоге выложили в Open Source и они остаются полностью открытыми по сей день. Подробнее об этих проектах мы ещё расскажем ниже.

В 2017 году мы сделали ставку на Okmeter ^[3] как систему мониторинга инфраструктуры. До этого наши инженеры уже перепробовали самописные скрипты и веб-приложения, Cacti, Zabbix и другие инструменты, но все было не то. И мы поняли: надо либо делать какое-то полноценное внутреннее решение, либо искать что-то готовое. Делать свое с нуля было бы долго и сложно, а достойный инструмент был нужен «уже вчера»: как минимум, от качества мониторинга зависели штрафные санкции, зафиксированные в SLA, а как максимум — уровень сервиса и наша репутация.

И хотя мы тогда этого не понимали, именно werf, shell-operator и Okmeter стали основой нашей будущей продуктовой экосистемы — причем все они появились в жизни «Фланта» примерно в одно время, в 2016-2017 годах. В последующих разделах статьи мы разберем, как эти продукты эволюционировали, как мы переосмыслили свой подход к их развитию и что с ними происходит сейчас. А в завершении расскажем, какие еще важные события произошли в жизни «Фланта» за последние пять лет.

werf: первый большой Open Source-проект, CNCF и капитан Флинт

В 2016 году мы начали работать над внутренним инструментом под названием dapp, который автоматизировал сборку Docker-контейнеров. Со временем он вырос в решение для управления всем жизненным циклом поставки программного обеспечения в Kubernetes. Это был не первый Open Source-проект «Фланта», но по масштабам он заметно превосходил все предыдущие. 

Dapp стал не просто какой-то небольшой утилиткой, он оказался связующим звеном для ряда других решений и процессов, превратившись в важный инструмент, который наши инженеры ежедневно использовали в работе. В нем мы реализовали свое видение того, «как делать правильно»: годами мы накапливали лучшие практики, оттачивали процессы CI/CD и наконец сумели автоматизировать их с помощью собственного программного решения.  

Когда ты оказываешь услуги, самое лучшее, что можно сделать для повышения эффективности — это унифицировать процесс оказания услуг. Dapp как раз выступил в качестве единого каркаса для построения процессов CI/CD в разных проектах, имеющих разные особенности и требования.

Со своей задачей утилита справилась: реализация CI/CD-пайплайнов была значительно упрощена, а инженеры получили что-то вроде тюбика клея, который позволял объединять и адаптировать под каждый проект стандартную связку популярных инструментов: Docker, Git, Helm, Container Registry, Kubernetes. Так у нас появился полноценный внутренний продукт. 

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

Из dapp в werf

Однако с dapp возникла небольшая проблема: название со временем стало все больше ассоциироваться ^[4] с разными блокчейнами. Поэтому 22 октября 2018 года мы начали придумывать для него другое название. Конечно, за основу взяли морскую тематику, моду на которую в DevOps-тусовке ввел Docker, а потом поддержал знаменитый «Кормчий ^[5]» — и речь не про старину Мао ^[6] По итогам обсуждений мы остановились на названии werf (на русском произносим как «верфь»).

Как мы выбирали название для werf

Первым вариантом был flint. Тут и знаменитый пират, и перекличка с Flant, и даже Flant Integration. Но в топик тут же набежали хейтеры (такова демократия!), которым новое название не понравилось:

 

Чтобы не зацикливаться на герое «Острова сокровищ», мы даже пошли изучать статью на Википедии ^[7] про морские термины. Но основная часть терминов из статьи уже была занята в доменной зоне io. Мы почти отчаялись, и даже поступило предложение потроллить своим названием всех морячков из экосистемы K8s.

Конечно, не обошлось и без Евгения Ваганыча и превращения айсберга в assberg… Попробовали даже рынду И тут Тимофея осенило (он, кстати до сих пор работает над werf):

werf — слово голландское и означает оно, собственно, верфь. Ту самую, судостроительную. На всякий случай пробежались по пиратским напиткам и оскорблениям вроде bastardo и даже был вариант kuklos — но вспомнились разные белые колпаки и он тут же отпал.

В 2019 году мы зарелизили документацию на русском языке ^[8], а 14 января 2020 вышла стабильная версия 1.0 ^[9] — и werf стала взрослым проектом.

Однако мы не только выложили werf в Open Source — со временем мы передали все права в Cloud Native Computing Foundation, некоммерческую организацию, которой принадлежат права и на Kubernetes. Официально передача прав состоялась 13 декабря 2022 года ^[10]. При этом мы до сих пор управляем развитием проекта и являемся его ключевыми мейнтейнерами. 

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

Развитие werf как продукта

Процесс развития werf — классика для технических Open Source-инструментов, которые выросли из внутренних проектов: мы собираем хотелки со своих инженеров, мониторим вопросы в чате werf ^[11] (eng ^[12]-версия), выступаем с докладами на российских и международных конференциях, пишем статьи, проводим опросы ^[13]. Это — наш feedback loop и главный источник пополнения бэклога. Кроме того, команда разработки werf постоянно следит за конкурирующими решениями в российском и международном коммьюнити.

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

Утилита пришлась по душе пользователям, сегодня у нее уже 3,6k звезд на GitHub — можно поставить звездочку и от себя.

Кстати, если вы используете werf в работе, напишите нам в чат ^[11] или в комментариях под этой статьей — мы хотим описать несколько кейсов и вообще поговорить о том, как ее используют за пределами «Фланта».

Дополнительные источники

• Сайт werf ^[14]

• GitHub ^[15]

• werf в CNCF ^[16] 

• Телеграм-канал werf ^[17]

• Самоучитель по CI/CD с werf ^[18] для разработчиков

• Первые шаги с werf: собираем и деплоим простое приложение в Kubernetes ^[19]

• werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада) ^[20]

• werf vs Docker. Чем лучше собирать образы ^[21]

Deckhouse: от Bash-скриптов до полноценной Kubernetes-платформы

Вернемся к другому нашему Open Source-проекту — shell-operator ^[22]. Мы обслуживали инфраструктуру клиентов и постоянно писали скрипты для автоматизации различных задач, в том числе связанных с K8s. Операторы — рекомендованный способ автоматизации задач в Kubernetes, и со временем мы пришли к логичному пониманию, что нам нужен инструмент, который  упростит и ускорит автоматизацию небольших задач силами DevOps-инженеров и системных администраторов. Обычно они знают Python и Shell/Bash, а вот Go, нативный язык для операторов под Kubernetes, — гораздо реже.

Так появился shell-operator, который позволяет подписаться на события от объектов Kubernetes, а когда получает их, автоматически запускает какую-то внешнюю программу (например, Bash- или Python-скрипт) и передает в нее информацию о событии. 

Из shell-operator в Deckhouse

Вообще, изначально shell-operator был неотъемлемой частью куда большего продукта — будущей Kubernetes-платформы. Но мы увидели в нем явный потенциал для прямого применения другими инженерами и решили выделить в отдельный проект, опубликовав ^[25] как Open Source на GitHub в 2019 году.

В то же самое время, благодаря существованию shell-operator, мы написали кучу модулей и операторов для настройки и автоматизации задач, связанных с Kubernetes. Делая многочисленные автоматизации на Bash, мы сразу четко осознавали, что это лишь временное решение — некий proof of concept. И когда это решение прошло проверку и заработало в реальных кластерах так, как нам надо, мы планово перешли к его переделке в нормальный вид — стали переписывать его на Go.

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

Первый коммит в свою Kubernetes-платформу, тогда еще закрытый внутренний проект под названием antiopa, мы сделали 24 сентября 2017 года. Создавая его, мы не стремились повторить путь других международных проектов или импортозаместить их — мы просто упаковывали в удобный (для себя же) формат тот опыт с Kubernetes, который накопился за годы работы с этой технологией.

В основу разработки платформы были заложены три принципа:

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

2. Платформа должна быть Open Source-продуктом. 

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

5 августа 2019 года мы стали выбирать название для это Kubernetes-платформы: в то время это был внутренний инструмент для использования в DaaS-командах, которые обслуживали клиентов, но мы уже понимали, что наша разработка может заинтересовать и более широкий рынок. В обсуждении всплывали самые разные варианты — от «Штурвала» и «Штурмана» до QUbertenas (не спрашивайте) и KFC (kubernetes flant cluster), но в итоге мы остановились на Deckhouse (корабельная рубка).

В апреле 2020 года произошла первая обособленная от услуги DevOps as a Service продажа программного решения. Так мы подтвердили гипотезу о том, что отечественная Kubernetes-платформа может быть востребованной не только на клиентских проектах по обслуживанию Kubernetes-инфраструктуры. 

Выход в Open Source и бизнес-модель

28 июля 2021 года Deckhouse уже появился в публичном репозитории на GitHub ^[26], были официально анонсированы две версии: бесплатная Community Edition и платная Enterprise Edition. Со стороны это может показаться чем-то довольно простым — вот есть исходники, вот они залетают на GitHub — но внутри была проделана колоссальная работа.

Что мы подготовили к публичному релизу:

• Переработали и дополнили техническую документацию.

• Создали телеграм-канал и чаты для общения с пользователями бесплатной версии.

• Создали сайт deckhouse.io ^[27] (на двух языках).

• Написали руководство по началу работы с продуктом (Getting Started).

• Начали собирать команду продаж Deckhouse (до этого мы продавали только услуги DaaS).  

Уже 6 августа 2021 года, спустя неделю после выхода в Open Source, Deckhouse прошел сертификацию CNCF ^[28], а в декабре был включен в реестр отечественного ПО ^[29]. Примерно в то же время в команде Deckhouse появился первый продакт-менеджер.

В 2022 году мы прошли проверку ^[30] на соответствие рекомендациям PCI Security Standards Council, сертифицировались ^[31] для работы с «Ред ОС», Astra Linux и AlterOS.

2023 год тоже был богат большими событиями. В феврале команда разработки добавила в Deckhouse модуль Virtualization ^[32] на основе KubeVirt ^[33], который позволяет управлять виртуальными машинами с помощью Kubernetes, а в марте — модуль Delivery ^[34] на основе werf и Argo CD для непрерывной поставки приложений в Kubernetes. Вовсю кипит работа над Deckhouse UI и сертификацией ФСТЭК.

Бизнес-модель Deckhouse и переосмысление понятия «продукт»

Бизнес-модель напрашивалась сама собой: мы верим в идеалы Open Source и хотим его продвигать, поэтому казалось естественным, что код Deckhouse будет открыт. Делать свое облако с Deckhouse и продавать его было бы слишком трудозатратно, а вот продавать лицензию на софт по модели Open Core ^[37] — самое то для компании, которая любит Open Source. 

В платной версии Deckhouse EE есть набор дополнительных фич, но она полностью основана на бесплатной версии (CE). То есть Deckhouse CE — реально работающая платформа, на которую мы даже помогаем переехать с enterprise-версии тем клиентам, которые перестают у нас обслуживаться в рамках услуги DevOps as a Service. 

Кстати, если вы используете Deckhouse Community Edition — напишите нам в чат ^[38] или в комментариях к этой статье, нам интересно, как CE запускается и работает без нашего участия, какие проблемы возникают и т.п.

Публичный релиз и начало продаж Deckhouse очень сильно повлияли на всю компанию — вот что мы поняли:

• Нужна отдельная команда для второй линии поддержки. Раньше на этой линии дежурили разработчики платформы, но теперь они «переехали» на третью и даже четвертую линии. 

• Чтобы соответствовать ожиданиям рынка и потребностям клиентов, необходимо наращивать команду разработки. 

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

Дополнительные источники

• Сайт Deckhouse ^[39]

• GitHub ^[40]

• Телеграм-канал Deckhouse ^[41]

• Чат по Deckhouse ^[38]

• Устанавливаем Kubernetes-платформу Deckhouse в закрытом окружении. Пошаговая инструкция ^[42]

• Разворачиваем Kubernetes-кластер на bare metal под управлением Deckhouse и создаем в нем виртуальные машины ^[43]

• Как устроена разработка Kubernetes-платформы Deckhouse (обзор и видео доклада) ^[24]

• Российский Kubernetes, какой он? Знакомимся с платформой Deckhouse ^[44]

Покупка Okmeter и мониторинг инфраструктуры

История Okmeter для нас — еще одна ступенька взросления компании. Одно дело — создавать собственные продукты и оказывать услуги, и совсем другое — купить готовый проект и начать вести его самостоятельно. 

Как мы уже упоминали, Okmeter был сторонним проектом, который мы с 2017 года использовали для мониторинга в рамках услуги DaaS. Какое-то время мы были основными пользователями системы — возвращались с обратной связью, делились своим опытом и подходами к мониторингу, просили добавить какие-то фичи и т.п. У нас даже были своя инсталляция Okmeter (хотя в основном он продавался по модели SaaS) и отдельный личный кабинет, в который мы заводили своих клиентов. 

Спустя несколько лет после начала работы с Okmeter мы поняли, что нам хочется все больше и больше влиять на процесс разработки инструмента и он хорошо вписывается в экосистему продуктов, которые мы уже планировали активно развивать. Мы пообщались с основателями Okmeter и оказалось, что у них есть идеи для новых продуктов, за которые им хотелось бы взяться более активно (кстати, недавно мы как раз написали обзор ^[45] на их новый инструмент — Coroot.). Сделка была взаимовыгодной: команда Okmeter получала ресурсы для разработки новых продуктов, а мы дополняли свою экосистему классным и хорошо известным нам готовым решением и могли развивать его так, как нам интересно. 

В мае 2021 года мы провели сделку ^[46], в результате которой Okmeter окончательно стал нашим стандартом для мониторинга железа, серверов, баз данных, приложений. 

Так как мы уже продолжительное время были сильно завязаны на Okmeter и уже хорошо знали его, сделка не казалась чем-то страшным. Конечно, определенные проблемы были: например, Okmeter базировался на самописном ядре хранения и обработки метрик, в котором был настоящий винегрет из технологий хранения данных — Elasticsearch, Kafka, Cassandra, PostgreSQL и т.д. 

К весне 2023 года мы перевели все хранение данных на Grafana Mimir ^[36]. Это заняло у нас примерно год: пришлось долго разбираться в чужом коде, обсуждать, как Okmeter будет развиваться дальше, переносить данные — да и ресурсы разработки были ограничены. Переход на новое ядро прошел бесшовно и незаметно для клиентов: мы сконвертировали и заменили все данные на лету. Okmeter стал работать ощутимо стабильнее.

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

Сейчас Okmeter включен в единый реестр российского ПО ^[47] и существует в двух вариантах: on-premise и SaaS. Кроме того, он входит в состав Deckhouse EE.

Дополнительные источники

1. Сайт Okmeter ^[48]

2. Телеграм-канал Okmeter ^[49]

3. Мимо тёщиного дома я без метрик не хожу (обзор и видео доклада) ^[36]

4. «Кому-то Okmeter даже сможет заменить людей». Как будет развиваться сервис мониторинга после его покупки «Флантом» ^[50]

5. Мониторинг PostgreSQL. Расшифровка аудиочата Data Egret и Okmeter ^[51]

Что еще случилось за последние пять лет

Помимо работы над тремя продуктами, мы продолжали развивать свое DaaS-направление и совершенствовать понимание бизнес-потребностей клиентов. Последнее давалось с трудом, потому что мы в первую очередь компания инженеров и больше привыкли к общению с техническими командами. Итак, что же еще у нас произошло за последние пять лет?

Осенью 2018 года наши инженеры начали получать ^[52] первые международные сертификаты Certified Kubernetes Administrator (CKA), которые выдает Cloud Native Computing Foundation (CNCF). Это позволило наладить внешнюю, объективную проверку навыков наших инженеров и дать им дополнительный инструмент для повышения собственной профессиональной ценности. В январе 2019 года мы получили «корочки» для всей компании, став первым Kubernetes Certified Service Provider (KCSP ^[53]) и Silver Member ^[54] в CNCF из России. 

В мае того же года мы начали активно выходить на крупный бизнес и запустили услугу «Kubernetes для enterprise». В рамках этой услуги мы предлагали крупным компаниям развёртывание и поддержку кластеров Kubernetes с применением своих лучших практик, а также обучение инженеров заказчика работе с этими кластерами. При этом за эксплуатацию рабочих нагрузок, размещенных внутри кластеров, отвечали внутренние команды клиента, а мы сопровождали и оказывали поддержку исключительно по K8s.

Но по-настоящему фокусироваться на enterprise-сегменте мы начали только спустя пару лет. И тут же столкнулись с проблемой: мы не умели работать с enterprise, не понимали его. Мы привыкли продавать свои услуги в СМБ-сегменте и говорить на языке простых технических и финансовых выгод: «Мы сделаем вот так и получится вот это». С крупными клиентами такой подход работает хуже: во-первых, в процесс переговоров вовлекается гораздо больше лиц, принимающих решения, а во-вторых, сами потребности enterprise могут быть очень далеки от понятных и прозрачных потребностей небольших компаний.

Мы начали выращивать собственные компетенции, но процесс шел слишком долго. И стало понятно, что это не очень продуктивный подход — нам нужен качественный прорыв. В 2022 году появилась такая возможность: компания Oracle ушла из России, и мы пригласили ее команду продаж во «Флант». Специалисты из Oracle имели огромный опыт взаимодействия с enterprise-сегментом, обладали обширными наработанными связями, а потому сумели в кратчайшие сроки выстроить работу с крупными клиентами и у нас.

Параллельно с развитием технической и бизнес-части «Фланта» росла и команда. В апреле 2021 года, за несколько месяцев до публичного релиза Deckhouse, нас уже было больше 100 человек — и с тех пор мы выросли еще вдвое. По состоянию на июнь 2023 года флантовцев уже более 200 ^[55]. Причем мы не останавливаемся: например, у нас идет активный наем Golang-разработчиков ^[56] в продуктовые команды. 

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

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

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

В-третьих, постоянно эволюционируют и наши процессы работы над клиентскими проектами, система менеджмента. Состояние системы на 2019 год зафиксировали и подробно описали в своих докладах наш основатель Дмитрий Столяров ^[57] и менеджер проектов Сергей Гончарук ^[58]. А об изменениях последних трех лет все тот же Сергей рассказал в своей недавней статье «Большая перемена: как за 3 года мы пересмотрели управление проектами во „Фланте” ^[59]».

Не забывали мы и про Open Source. В 2018 году мы выложили в открытый доступ ^[60] плагин Grafana Statusmap panel ^[60], который позволяет отобразить состояние набора объектов за выбранный промежуток времени (и на сегодня его скачали более 35 миллионов раз!), и kubedog ^[61], Go-библиотеку и CLI на её основе для отслеживания событий ресурсов Kubernetes. В апреле 2022 года выпустили утилиту trdl ^[62] для непрерывной и безопасной доставки обновлений (мы используем её для werf, но проект может оказаться полезным и отдельно от нее).

Кроме того, мы активно работаем над многими международными Open Source-проектами — например, в 2023 году наконец довели до релиза два KEP (полноценных фичи) в рамках системы аутентификации Kubernetes. Первый ^[63] добавил API для просмотра атрибутов текущего пользователя после завершения процесса аутентификации, а второй ^[64] обеспечивает удобный способ конфигурации OIDC и является крупнейшим обновлением в аутентификации за последние годы.

Дополнительные источники

• 10 лет on-call. Чему мы научились? (обзор и видео доклада) ^[57]

• Управление распределенной командой в режиме многопроектности (обзор и видео доклада) ^[58]

• Большая перемена: как за 3 года мы пересмотрели управление проектами во «Фланте» ^[59]

• Kubernetes 1.26: обзор нововведений, включая первый KEP «Фланта» ^[65]

Итог

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

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

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

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

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

P.S. Ну что, встретимся в новой статье еще через 5 лет?