SLO — это практика, входящая в состав SRE-методологии, которая помогает найти баланс между скоростью развития сервиса и его надёжностью.
В статье хочу поделиться опытом внедрения SLO в наш продукт и рассказать, какие результаты это принесло. Или как мы применяем инженерный подход к решению менеджерской задачи
К тому, что описано в статье, мы пришли через череду даунтаймов и багов, которые приходилось править “на горячую”. Происходили сбои во время бета-теста, но все равно тема обеспечения стабильной работы для нас болезненная. За знания пришлось заплатить дорогую цену - неудобства пользователей. Мы сами еще только на полпути к построению той системы обеспечения стабильной работы, какой нам бы хотелось ее видеть. Но надеюсь, наш опыт поможет кому-то не повторять наших ошибок и сразу все сделать правильно.
Статья не имеет цели создать какое-то принципиально новое знание о мониторинге, которого нет у опытного SRE инженера. Но, возможно, будет полезна в качестве отправной точки для изучения технологического стека тем, кто только начинает погружаться в вопрос.
Начнем с того, в каких случаях и какой мониторинг обычно используется.
В мае 2023 года «Фланту» исполнилось 15 лет. За это время из небольшого предприятия двух друзей-студентов, которые мечтали поставить GNU/Linux на каждый рабочий стол, мы выросли в команду опытных и уважаемых в индустрии DevOps-инженеров и постепенно трансформируемся в продуктовую компанию с собственной экосистемой продуктов.
В этой статье мы хотели порефлексировать о переходе от сервисной компании к созданию собственных продуктам, рассказать, как эти продукты развивались и что с нами произошло за последние 5 лет.
Сразу обозначим свой «символ веры». Услуга DevOps as a Service (DaaS) была, есть и будет основой нашей продуктовой линейки. Именно благодаря инженерам, которые 24/7 обслуживают сотни клиентских кластеров, мы можем получать максимально быстрый фидбэк по своим продуктам, тестировать новые релизы и собирать кучу новых идей для дорожной карты. То есть в нашем случае услуга, как бы странно для классических продуктовых компаний это ни звучало, является одним из ключевых компонентов продуктовой разработки.
Это история о том как небольшая группа IT-шников хотела автоматизировать свою работу, а в результате решила переизобрести DevOps-заново, и (с точки зрения этой группы) добилась прогресса.
От предыдущего этапа нашей деятельности у нас осталось множество IT-разработок. Какие-то остались недоделанными, какие-то были выпущены в продакшен, какие-то были опубликованы как open source, какие-то остались закрытыми, какие-то нужно было архивировать, а какие-то опубликовать как демо-версии. Всё было свалено в кучу на нескольких VPS-ках. И чтобы продолжать деятельность, стало важно привести все это во вменяемый вид...
Разработка надежной, масштабируемой и эффективной системы может оказаться довольно сложной задачей. Однако понимание основных принципов и компонентов этого процесса может сделать его более управляемым. В этой статье мы рассмотрим основные компоненты в проектировании систем, такие как DNS, балансировка нагрузки, API-шлюз и другие. Также мы предоставим краткую схему, которая поможет разработчикам проектировать системы различной сложности.
Узел K8s — это физическая или виртуальная машина, участвующая в кластере K8s, которая может использоваться для запуска подов. Когда узел выключается, выходит из строя или процесс kubelet сталкивается с проблемой, узел переходит в состояние NotReady. Он не может использоваться для запуска подов. В этом случае все запускаемые на узле поды становятся недоступными.
Обычными причинами перехода узла K8s в состояние NotReady являются:
Задумывались ли вы о переходе из кодинга фич в сторону инфраструктурной разработки? Любопытство к SRE практикам растет, поскольку устойчивость и надежность приложений стали главными факторами успеха на рынке. В этом материале мы собрали для вас успешные карьерные кейсы действующих SRE-инженеров.
Кубернетес использует примитивы Linux в качестве строительных блоков для своей собственной сетевой модели. Сеть в Кубернетес представляет из себя сложную для понимания и для администрирования систему. Однако, большая часть из привычных для системных администраторов и сетевых инженеров, инструментов доступна и для Кубернетес. Навыки, приобретенные, за годы работы с привычным технологическим стеком можно применить для решения проблем в системе Кубернетес.
Аннотации в Kubernetes (K8s) — это метаданные с дополнительной информацией, связанной с ресурсом или объектом. В этой статье разберемся, что они из себя представляют, для чего служат и чем отличаются от меток.
В современном быстро меняющемся цифровом мире автоматизация является важной частью стратегии любой организации. С распространением облачных вычислений, DevOps, непрерывной интеграции и доставки спрос на инструменты автоматизации вырос в геометрической прогрессии. Ansible — инструмент автоматизации с открытым исходным кодом, который стал одним из самых популярных решений для автоматизации управления инфраструктурой, развертывания приложений и управления конфигурацией.
В этом посте мы рассмотрим, как Ansible может помочь вам автоматизировать всё в вашей инфраструктуре.
Продолжая серию статей про знания, полученные на работе, хочу рассказать про свои навыки DevOps, которые были на нуле, когда я пришла в компанию GlowByte.
Это история о том, на что нужно обращать внимание, изучая инструменты DevOps с нуля, и как достичь успеха в этом.
В статье расскажу свою историю накопления знаний, какие задачи помогли лучше понять DevOps и как это все помогает специалисту поддержки.
Есть такие ребята — SRE (с англ. Site Reliability Engineering), которые выросли из старых добрых и бородатых системных администраторов. Но они устали заниматься ежедневной рутиной и решили всё автоматизировать. Именно поэтому 50% времени SRE пишут код.
DevOps- и SRE-командам важно знать как можно больше о работе приложений, за которые они отвечают: как эти приложения работают в разных условиях, как их показатели меняются со временем, в какой точке можно ускорить работу, тем самым улучшив показатели производительности и доступности сервисов. Для всех этих задач важны показатели наблюдаемости (observability). Реализовать наблюдаемость можно при помощи технологии eBPF, которой уже более 10 лет.
Чтобы легко адаптировать статистику eBPF и получать из нее полезную информацию, нужен дополнительный инструмент. Одним из них и является Open Source-решение Coroot. Coroot — это observability-инструмент, который превращает данные телеметрии в полезную информацию, помогая быстро выявлять и устранять проблемы с приложениями. В статье проверим, какие у него есть возможности.
Подробно и на примере рассматриваем проблему deployment bottleneck и как она появляется. Рассказываю как можно легко и быстро настроить реплицируемые stage-окружения для ее решения, дав разработчикам делать свою магию параллельно и независимо друг от друга.
Развёртывание ПО, или деплой (deploy) — этап в разработке, в Devops в целом, это действия, которые делают ПО готовым к использованию. Если вы умеете в грамотный деплой, масштабирование и управление конвейерами (CI/CD), то ваш софт будет конкурентоспособным.
Далеко не все компании могут позволить себе нанять целую команду DevOps инженеров, чтобы управлять развёртыванием. Но здесь важно не количество разрабов, а качество их знаний. Есть инструменты, с которыми можно эффективно деплоить и без большой команды.
Мы в digital-агентстве успешно используем GitLab CI и Docker для развёртывания ПО в разных средах. Для чего нужны эти инструменты?
GitLab CI позволяет автоматизировать процессы сборки и доставки ПО. Docker — упаковать приложение и его зависимости в контейнеры, что упрощает развёртывание и масштабирование в разных средах. Используя их, вы сократите затраты на найм и оптимизируете деплой.
В этой статье расскажу о нашем опыте и покажу примеры настройки конвейеров CI/CD, как ими управлять с помощью GitLab CI и Docker. А также дам рекомендации, как масштабировать развертывание.
IT-сфера большая и многогранная. В ней обитают разработчики, сисадмины, инженеры и многие другие. Как правило, каждый специалист имеет конкретную зону ответственности и действует в её рамках. Однако сегодня всё чаще встречается мнение, что разработчикам было бы неплохо хотя бы на базовом уровне разбираться в DevOps-инструментах — «понимать, что окружает их кроме кода».
Мы пообщались с Владиславом Килиным — тимлидом в компании Coolblue.nl — и узнали, как понимание DevOps-инструментов помогает разработчику улучшать рабочие процессы и эффективно справляться с задачами.
Всем привет. Мы давно не писали на тему менеджмента команд и проектов. Начнем с краткой вводной. Помимо продуктовой разработки, которой мы занялись около 5 лет назад, основным направлением деятельности «Фланта» остается DaaS (DevOps as a Service). Мы помогаем клиентам с обслуживанием инфраструктуры. И эта деятельность накладывает большой отпечаток на наш внутренний процесс управления проектами, так как у нас много специфичных процессов и практик: у команды может быть несколько разноплановых проектов, ей необходимо обеспечить SLA по каждому из них. Важно и то, что наши команды на 100% удаленные.
Три года назад нам казалось, что мы нашли лучшее решение для управления распределенными командами и многочисленными проектами. Но это оказалось не так. С тех пор в нашей работе произошло столько изменений, что нам пришлось полностью пересмотреть модель таск-менеджмента. В этой статье мы проследим, как и почему появлялись новые практики и как они повлияли на эволюцию наших процессов.
Если ваш сервис или ПО связаны с пользователями, рано или поздно встаёт вопрос авторизации, аутентификации и хранения этих чувствительных данных. Кто-то изобретает велосипед сам, кто-то использует многолетние enterprise-решения, ну а мы решили изучить вопрос и найти наиболее удобный, экономичный и гибкий вариант для своих задач. Расскажем, как мы это делали, какие были трудности и удалось ли их решить.
Хабр, привет!
Меня зовут Александр Кузьмин, я старший инженер в КРОК, занимаюсь облачными технологиями, микросервисами и всеми новомодными DevOps-методологиями.
В этом посте хочу поговорить про Kubernetes, а именно — про организацию доступа в кластер. Развернуть кластер несложно, а вот постоянно поддерживать его в рабочем состоянии — это задачка уровнем выше. И здесь не избежать вечного вопроса «как сделать так, чтобы Вася не сломал то, что придумал Петя». В посте рассказываю, как мы работаем с этим в КРОК: какие механизмы ограничения доступа используем, как их подбираем и какие важные моменты учитываем. Всё в деталях, как мы любим на Хабре — с подробными пошаговыми описаниями, лайфхаками из личного опыта и удобной шпаргалкой в конце.
Пост основан на моем докладе на последнем DevOops Conf, так что если видео вам заходит лучше, приглашаю по ссылке.