DevOps Brain 🧠
1.21K subscribers
127 photos
16 videos
119 links
Пишу про kubernetes, terraform, linux, сети, автоматизации и полезные тулзы. Без спама и щитпостинга.

Хотите пообщаться? @devopsbrain_chat

Автор: @itcaat
Download Telegram
Недавно в twitter спрашивал о том, есть ли практика ведения посмортемов. Оказалось, что не такой большой процент заботит эта история. И были даже кейсы, когда просили лида внедрить такую практику, но лид сливался. 😱 Давайте сегодня чуть ближе познакомимся с этим очень важным и нужный инструмент.

Постмортем ([лат.] «после смерти») — это анализ инцидента, произошедшего в системе, и его последствий. В сфере DevOps/SRE равно как и в разработке продукта постмортемы играют ключевую роль для повышения устойчивости и надежности инфраструктуры. Выделим несколько ключевых моментов о постмортемах и как сделать их полезным инструментом для роста вашей команды.

💀 Принципы «Blameless» постмортемов

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

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

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

💀Составляющие хорошего постмортема

Успешный постмортем состоит из нескольких важных этапов:

1️⃣ Описание инцидента. Кратко и четко изложите, что произошло. Например: «API перестало отвечать на запросы из-за превышения лимита соединений в базе данных».
2️⃣ Причины. Опишите, какие факторы привели к инциденту. Это может быть комбинация технических проблем, недоработок в процессах или неожиданного поведения системы.
3️⃣ Реакция команды. Зафиксируйте действия, которые предпринимались для устранения проблемы, и как быстро был восстановлен сервис.
4️⃣ Уроки. Что можно улучшить в будущем? Нужно ли пересмотреть мониторинг, переработать конфигурации или оптимизировать процессы развертывания?
5️⃣ Действия на будущее. Определите конкретные шаги, которые помогут избежать повторения инцидента. Это может включать добавление мониторинга для критичных метрик, улучшение документации или изменение архитектурных решений.

💀Автоматизация и инструментальная поддержка

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

💀 Ретроспективы — следите за прогрессом

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

💀 Польза посмортемов для всех
🔥4👏1
Инженеры могут улучшить качество своей работы за счет углубленного анализа причинных факторов инцидентов.
Помогают выявить недостатки в коде, которые могут вызвать инциденты в будущем, и дают возможность быстро их устранить.
Это отличная возможность для разработки новых инструментов и процессов, улучшающих стабильность системы.
Позволяют улучшать процессы мониторинга и алертинга, что предотвращает повторение проблем.
Дают новые знания о том, как системы ведут себя в реальных условиях, и что можно улучшить в архитектуре и инфраструктуре.
Помогают повысить общую надежность системы и уверенность в поддержке её работы при высоких нагрузках.
Анализ инцидентов снижает риски повторных сбоев, что напрямую влияет на качество предоставляемых услуг и удовлетворенность клиентов.
Понимание корневых причин и внедрение улучшений обеспечивает стабильную работу сервисов, что способствует росту репутации компании.
Шаринг знаний между котлегами.

💀💀💀 Кстати, деплой в пятницу, как раз может стать поводом написать свой первый посмотрем 💀💀💀
🔥3
Накатал некий аналог service discovery для VMs и Nodes в кластере proxmox ( если вы не юзаете SDN). Принцип работы максимально простой. Фигачите обслуживание зоны (например proxmox.example.com) в proxmox-service-discovery (желательно в 2 экземплярах конечно - ну вы поняли почему). Дальше тула забирает по API все нужные данные для отдачи IP адреса и отдается по 53 (UDP, DNS)

Мапа из A записей в памяти собирается из нод, имен VM и тегов ( если нужно )

Сама тула тут https://github.com/nrukavkov/proxmox-service-discovery
🔥3
В эту прекрасную пятницу ( а прекрасная она потому что на следующей неделе я ухожу в отпуск ), делюсь порцией крутых статей и видосов

1️⃣ https://habr.com/ru/articles/852536/ - Maxpain рассказывает как искал нашел баг в параметре ядра linux и раскопал причину медленной работы дисков в Talos Linux. Много графики, полезных тулов и в целом читается на одном дыхании.

2️⃣ https://github.com/rcoh/angle-grinder - Angle grinder предназначен для случаев, когда у вас нет данных в graphite/honeycomb/kibana/sumologic/splunk/и т.д., но вы все равно хотите иметь возможность выполнять сложную аналитику. Позволяет вам в реальном времени анализировать, агрегировать, суммировать, усреднять, находить минимум и максимум, процентиль и сортировать ваши данные.

3️⃣ https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ - Andrew Locks рассказал про фичу --update-refs для ребейзов в Git 2.38. Автор показывает различные сценарии использования --update-refs. Если вы хотите чего то нового в git - то вот оно!

4️⃣ Ну и из лайтового могу порекомендовать просмотреть видос на 20 минут про Redis. Автор (канал suchkov tech) отлично показал на примере как работает редиска на живом приложении и как в принципе кеш позволяет ускорить работу приложения минимум в несколько раз https://www.youtube.com/watch?v=QpBaA6B1U90

Ну а на этом все - всем спасибо и хорошей пятницы! 🤗️️️️️️
👍4🔥2🦄1
Channel name was changed to «DevOps Brain ✈️»
Отпуск “потрачено”. Press F

👨‍💻 Нашел хипстерский htop под macos https://github.com/Abdenasser/neohtop. Пользоваться, конечно не буду, старый добрый htop все равно лучше - все таки в консоли привычнее. Но дизайн прикольный. А вам как?

#tools #macos
👍4👏1
Сначала Линупс Торвальдс выпилил код российских разработчиков из ядра. Теперь вот тут отклонили PR за русскость https://github.com/reactor/reactor-core/pull/3897#issuecomment-2460103961.

А сегодня я орнул. Короче, есть такая прикольная штука для доставки миграций в базы bytebase зовется. Штука реально крутая, работать можно практически с любой субд, есть gitops, разные флоу, роли права доступа и тд. Ну красота в-общем. Но есть один косячек который глаз мозолит - поскольку у нас оно запущено в кубе, то конечно хочется что бы контейнер bytebase отдавал в логи в json. Пошел я искать как можно это реализовать и нашел кусочек недокументированного кода, где задать вывод лога в json можно сделать через параметр saas. Причем параметр влияет еще на кучу всего в приложении и юзается для их клаудовой версии. Ну думаю "непорядок" - надо запилить пулик и вынести все в отдельный параметр.

Закидываю пулик https://github.com/bytebase/bytebase/pull/14375 и получают фейл чекам verification/cla-signed и коммент

We require contributors to sign our Contributor License Agreement, and we don't have yours on file. In order for us to review and merge your code, please sign CLA and add your name to contributors list.

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

OpenSource явно свернул куда то не туда, скоро скрин паспорта походу надо приложить будет. 💩 А так инструмент, конечно, классный - рекомендую кто не юзал. Всем хорошей пятницы.
😱3🤯2
Давайте познакомимся с таким инструментом как grafana k6. С помощью него вы можете производительность ваших приложений и тестирование хаоса (Это метод, используемый для проверки устойчивости программных систем путем внесения непредвиденных сбоев или сбоев. Целью хаотического тестирования является выявление слабых мест и повышение устойчивости приложения)

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

Ниже пример моего кейса. Надо было протестировать как себя ведет балансировщик. Поскольку балансер еще работает не в боевом режиме, надо отправить на IP адрес балансера заголовок с нужным хостом и игнорированием https. В примере мы в течении 30s плавно повышаем нагрузку до 1000 виртуальных пользователей, держим 30 секунд и далее в течении 20 секунд уменьшаем нагрузку до 0.


import http from "k6/http";
import { check, sleep } from "k6";

// Test configuration
export const options = {
thresholds: {
// Assert that 99% of requests finish within 3000ms.
http_req_duration: ["p(99) < 3000"],
},
stages: [
{ duration: "10s", target: 1000 },
{ duration: "30s", target: 1000 },
{ duration: "20s", target: 0 },
],
// ignore ssl valudation
insecureSkipTLSVerify: true,
};

// Simulated user behavior
export default function () {
const url = "https://my.loadbalancer.ip.address"; // Set load balancer host

// set header hosts
const headers = {
Host: "example.com",
};

let res = http.get(url, { headers });

check(res, { "status was 200": (r) => r.status == 200 });

sleep(1);
}


В результате вы получите супер подробный отчет по производительности.

На самом деле это довольно базовый сценарий, но сила k6 в возможности наращивать и усложнять логику, ограниченную только вашей фантазией. Примеры использования вы найдете в официальной документации https://grafana.com/docs/k6/next/get-started/running-k6/
👍4🔥2🆒1
Нашел консольный аналог postman - как вам? По-моему выглядит круто, там даже command palette есть 🤯Правда ставится через uv. 🙁

https://github.com/darrenburns/posting

#tools
👍5🔥2
Мониторинг и алертинг - это база. Без них не может нормально ехать ни один продукт и ни один бизнес. Если говорить про IT, то чтобы иметь полную картину у вас должны быть:

🟢 Infrastructure-related alerts - например, высокая утилизация CPU на ноде
🟢 Application-related alerts - например, прилка начала сыпать 500-ми ошибками
🟢 Business-related alerts - например, снижение конверсии

✍️ Давайте разберем простой кейс, вам прилетел алерт на CPU от ноды с postre в проде. Дежурный инженер открывает борду в grafana ( или zabbix ), смотрит какие то общие показатели. Потом подключается к базе, смотрит какие запросы сейчас обрабатываются, читает логи и тд. И принимает дальнейшие решения по тому в кого эскалировать проблему или решает вопрос сам. И вот этот порядок действий практически всегда один и тот же.

🔛 Как было бы круто дообогатить алерт уже подготовленной информацией. Например, получить вместе с алертом список выполняющихся сейчас запросов в базе и их потребление по ресурсам. (Например, через SELECT pid AS process_id, query AS active_query FROM pg_stat_activity WHERE state = 'active'; )

🧠Вот ребята из keephq тоже так подумали и запилили просто офигенскую прилу, добавив нереальное количество интеграций (провайдеров), которые можно интегрировать в различные флоу обработки алертов

Просто взгляните на список провайдеров: AKS, AppDynamics, Auth0, Axiom, Azure, BigQuery, Centreon, Chat, Checkmk, Cilium, Clickhouse, Cloud, Cloudwatch, Coralogix, Datadog, Discord, Elastic, GCP, GKE, GitHub, GitLab, Google, Grafana, Graylog, Incident, Jira, Kafka, Kubernetes, Linear, LinearB, Mailchimp, Manager, Mattermost, Microsoft, MongoDB, Monitor, Monitoring, MySQL, Netdata, New, Now, On-Prem, OnCall, OpenAI, OpenObserve, Openshift, OpsGenie, PagerDuty, PagerTree, Pipelines, Planner, PostgreSQL, Pushover, QuickChart, Redmine, Relic, Resend, Rollbar, SIGNL4, SMTP, SSH, SendGrid, Service, SignalFx, Slack, Snowflake, Splunk, Squadcast, Statuscake, SumoLogic, Teams, Telegram, Trello, Twilio, UptimeKuma, Webhook, Zenduty

https://github.com/keephq/keep

Я пока сам не тестровал, но выглядит это просто 🔥 В ближайшее время буду поднимать и тестировать, а результатами поделюсь с вами 👍
🔥11👍1🍓1
Всем привет! А давайте разыграем новенькую обложку на паспорт с лого github 🍾

Оставляй коммент "хотеть это" (или любой другой) и в понедельник выберем победителя великим рандомом. 😁
👍3🐳2
Всем доброго утра. Я к вам с отличной новостью.

Теперь github copilot for vscode бесплатный. Никаких подписок, триалов, карточек не требуется.

Более того, вы можете сами решать какую модель использовать.

Как активировать и другие подробности по ссылке: https://code.visualstudio.com/blogs/2024/12/18/free-github-copilot
🔥7💯2
😁10
Всем привет. Надеюсь, все выжили после праздников и готовы делать мир лучше (или хуже - тут уж от каждого по способностям каждому по потребностям). 🎅

Я вам вакансию принес на Junior Devops Engineer, не проходите мимо кому актуально
https://www.aviasales.ru/about/vacancies/3870114
🔥6
Всем привет, я тут показывал недавно как сделать такую красоту котлеге и сразу записал небольшой гайд. Хотите такой же zsh на стеройдах? Без проблем!

Будем юзать Oh My Zsh, который позволит нам получить:

Автодополнения команд (например, Docker).
Алиасы для сокращений (например, gcb – создание ветки).
🎨 Красивую кастомизацию с темами.

# 1. Устанавливаем oh my zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# 2. Устанавливаем шрифты
git clone https://github.com/powerline/fonts.git --depth=1
cd fonts
./install.sh
cd ..
rm -rf fonts

# 3. Устанавливаем rvm-prompt, чтобы тема не плевала ошибку
curl -sSL https://get.rvm.io | bash

# 4. Устанавливаем тему
git clone https://github.com/consolemaverick/zsh2000.git
ln -s $(pwd)/zsh2000/zsh2000.zsh-theme ~/.oh-my-zsh/themes/zsh2000.zsh-theme


Теперь пропишем нужные плагины. Полный список всех плагинов есть по ссылке https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins c детальным описанием. В любом удобном редакторе открываем ~/.zshrc и прописываем параметры.

ZSH_THEME="zsh2000"

plugins=(
git
macos
docker
docker-compose
)


В настройках терминала выставляем шрифт на Meslo LG M DZ for Powerline, Regular, 11px. Перезапускаем терминал и радуемся.
🔥3
В продолжении темы про терминалы - недавно наткнулся на https://tabby.sh. Я погонял его пару дней - есть небольшие баги, но в целом как альтернативна терминалу очень даже огонь.

🟢 Работает на Windows, Mac и Linux.
🟢 Встроенный SSH-клиент с менеджером подключений.
🟢 Встроенный терминал для работы с последовательными портами.
🟢 Поддержка PowerShell, PS Core, WSL, Git-Bash, Cygwin, Cmder и CMD.
🟢 Полная поддержка Unicode, включая символы двойной ширины.
🟢 Передача файлов в/из SSH-сессий через SFTP и Zmodem.
🟢 Темы оформления и цветовые схемы.
🟢 Полностью настраиваемые горячие клавиши, включая составные комбинации.
🟢 Запоминает ваши вкладки и разделенные панели.
🟢 Полноценный опыт работы с Shell на Windows, включая автодополнение.
🟢 Встроенный зашифрованный контейнер для хранения SSH-секретов и настроек.

#tools
👍1👏1
📎 Dive in performance tools. Часть 1️⃣ [sysdig]

Котлеги, привет. Вдохновленный серией статей от Евгения Козлова про CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async, я решил написать свой цикл статей по инструментам диагностики производительности linux с примерами.

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

Long story short - sysdig использует модуль ядра для перехвата системных вызовов и событий, что открывает нам невероятные возможности в плане диагностики. Вы буквально можете расковырять практически все что происходит у вас в системе. Можно использовать realtime-диагностику или собрать трейс с системы за определенный период, обычно при проблемах достаточно до 30 секунд сбора данных.


# Установка sysdig
curl -s https://download.sysdig.com/stable/install-sysdig | sudo bash


Есть небольшой минус - sysdig требует заголовки ядра (kernel headers), потому что он использует модуль ядра для перехвата системных вызовов и событий. Но глобально это влияет только на скорость установки и требуется немного места.

Допустим у вас есть какая-то лагучая нода и базовые инструменты дигностики/логи вам не особо помогли. Давайте посмотрим на живом примере как ее использовать.


# Запускаем запись всех эвентов на 30 секунд
sysdig -w capture.scap -M 30


Конечно можно не использовать GUI, а вытащить из трейса событий нужные данные. Но это обычно работает, если вы точно знаете что искать. Например так] (без GUI)


# Вывести срезы которые доступны в этом трейсе (тут вы получите список срезов в различных категориях. Например, bottlenecks - cамые медленные системные вызовы)
sysdig -r capture.scap -cl

# выведем top процессов утилирующих cpu
root@server:~# sysdig -r capture.scap -c topprocs_cpu
CPU% Process PID
--------------------------------------------------------------------------------
15.00% redis-server 1095390
12.60% redis-server 1095391
12.20% redis-server 1095375
....


# Показать top файлов с которыми велась работа (R+W)
root@server:~# sysdig -r capture.scap -c topfiles_bytes proc.name=redis-server
Bytes Filename
--------------------------------------------------------------------------------
72.00M /data/temp-27.rdb
40.00M /data/temp-28.rdb
82.72KB /proc/self/stat
.....


Как я и сказал ранее, все эти данные есть в realtime и можно просто запустить GUI csysdig, но проблема может быть плавающая. В таком случае есть шанс просто пропустить нужные данные. Поэтому, я рекомендую снимать трейс эвентов и работать с ним.


# Открываем консольный GUI и скармливаем ему capture.scap
csysdig -r ./capture.scap


После этого переходим в режим Views (F2) и можем нырять на столько глубоко на сколько у вас хватит фантазии.

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

А на этом все - спасибо за внимание.

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

Ссылка на habr: https://habr.com/ru/articles/876160/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥12
Channel name was changed to «DevOps Brain»