DevOps *

Вам сказали развернуть систему мониторинга, вы выбрали связку Prometheus + Grafana. Развернули Grafana на своих серверах (VM/Docker/Kubernetes) и подключили Data Source Prometheus (а возможно вам еще сказали развернуть логирование и вы используете Grafana Loki) и далее по гайдам из ютуба начали создавать свои дашборды и настраивать алерты.

Все работает идеально, но в один момент вы начинаете думать о том, чтобы хранить созданные сущности Grafana в коде, чтобы их можно было легко восстановить в случае потери данных или же развернуть при создании новой среды (dev/prod). Экспортировать дашборды не составит труда, это можно сделать и через GUI, но как же источники данных, политики уведомлении, contact points и сами алерты?

Знакомая история? Возможно, что нет. А у меня да!

Соглашение об уровне обслуживания (SLA) – это соглашение с клиентами или пользователями, где описывается уровень обслуживания, который поставщик обещает предоставить клиенту. SLA можно представить в виде измеряемой метрики, например, как время безотказной работы или суммарное количество ошибок. Перевели статью, где рассматривается простой способ расчета SLA на примере Nginx-сервера.

Эксперты Платформы Сфера впервые провели исследование российского рынка инструментов DevOps. Они проводили его с декабря 2022 по конец февраля 2023. 

Подробнее о них расскажет нам Евгений Калашников, руководитель портфеля продуктов для разработчиков в T1. Он представит нам отчёт с объёмами, преимуществами инструментов DevOps.

Недавно передо мной встала задача — есть 250 тестов, каждый из которых занимает от 5 до 30 минут, а иногда и часы. Надо запустить их в параллель на одной машине, но не больше 16 одновременно. Ограничение связано с некоторым лимитированным ресурсом, а также количеством ядер CPU. Реальное число одновременно запущенных задач нужно вычислять динамически, то есть пойти простым путем и зарегистрировать имя или лэйбл ресурса заранее с помощью плагина Lockable Resource не получится.

Проблемы роста — обычное дело, и базы данных в этом смысле не исключение. Полтора года назад команда Loki задумалась о том, как на порядок повысить кардинальность (cardinality), производительность запросов (query throughput) и надежность (reliability). Работа над новым индексным слоем почти закончена — время остановиться и посмотреть: что же мы делаем, чтобы оставаться на пике прогресса.

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

• Есть учетная запись (УЗ) в keycloak с правами админа на какой-то веб-ресурс. Как, используя keycloak, сделать так, чтобы для входа админу требовался дополнительный фактор аутентификации?
• Есть веб-ресурс (client в терминологии keycloak). Как дать доступ к этому веб-ресурсу средствами keycloak на этапе аутентификации определенной группе пользователей (в ситуации, когда это не реализовано самим приложением)?

Здравствуйте, меня зовут Павел.

Я работал системным администратором с 2010 года в разных компаниях, в 2019 году решил сменить сферу деятельности на DevOps-инженера.

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

Работая в компании, этот вариант отчёта я создал в виде джобы в Jenkins (Pipeline + Bash), отчёт создавался только для определённых тестовых стендов и для определённой программы.

Через некоторое время появилась мысль создать свою универсальную      кроссплатформенную программу на Java для простого создания DevOps-отчётов.

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

Почитав на просторах интернета статьи о лицензировании при использовании JDK и Open JDK, чтобы не было проблем с авторскими правами, я принял решение использовать Open JDK Amazon Corretto 11.

В качестве GUI интерфейса выбрал JavaFX. Программу назвал «DevOps Report Manager».

Далее, вооружившись книгой «Java Руководство для начинающих» и Интернетом, начал создавать первую часть программы.

Привет, я Сергей, техлид банка «Центр-инвест» и один из авторов курса «DevOps для эксплуатации и разработки». Раньше занимался написанием бэкендов на Java и Kotlin для финтех-энтерпрайза, потом занялся архитектурой, выстраиванием процессов и залез в DevOps. Заношу DevOps-практики, техлижу и деврелю.

В этой статье я расскажу:

• Почему DevOps — это круто и нужно;

• С чего начать свой путь в DevOps;

• Кто такой T-shape-специалист;

• Как мыслят истинные инженеры;

• Что почитать, куда сходить и на что посмотреть.

Привет! На связи Василий Мармер, DevOps-тимлид компании «Флант». Сегодня мы поговорим об Atlas — еще одной утилите, которая делает работу DevOps-инженера более комфортной. Atlas увидел мир в ноябре 2021 года, а сейчас у него более 3,3 тысячи звёзд на GitHub. Язык программирования — Go.

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

Привет, Хабр! На просторах интернета, да и на самом Хабре есть огромное количество статей про OCR. Сегодня я бы хотел рассказать не про процесс распознавания текста а про методику развертывания решения в закрытом контуре (проще говоря - без интернета).

«Архитектура с эволюционным развитием поддерживает управляемые, постепенные и последовательные изменения сразу в нескольких направлениях».

Из книги «Эволюционная архитектура. Поддержка непрерывных изменений»

В конце прошлого года нам поступила задача по реализации отказоустойчивого хранилища для разрабатываемого сервиса.

Ранее для этих целей предложили бы готовое решение в виде СХД с поддержкой сетевых протоколов вроде Hitachi NAS Platform (HNAS). Но текущая ситуация и особенности контракта обязывали проработать решение на мощностях заказчика.

В итоге выбрали и реализовали решение с использованием ОС на ядре Linux и кластере PaceMaker — с общим диском, поддержкой кворума, демона SDB и протокола NFS. Кому интересны особенности реализации, прошу под кат.

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

Под катом вы узнаете как установить оптимальные значение connection и request timeout, стоит ли повторять запрос при ошибке или лучше избегать этого.

В конце статьи есть небольшая шпаргалка и куча полезных ссылок. Приятного чтения.

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

Команда разработчиков Trendyol Tech видоизменила архитектуру и решила эту проблему с помощью outbox-шаблона, но столкнулась с другой проблемой — дублированием событий. Приводим перевод статьи о том, как разработчики залезли под капот Kafka и нашли решение этих двух проблем.

Подходы к оптимизации процессов разработки и развертывания хорошо известны и задокументированы: DevOps, SRE, облачные сервисы вроде Containerum Kubernetes или DBaaS for PostgreSQL и т. д.

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

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