Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в Авито. В этой статье я расскажу про инструмент, который мы используем для обнаружения деградаций на нодах в кластерах Kubernetes, а также покажу дашборд, где мы наблюдаем за состоянием всех наших нод.

В последние годы перед инженерами нередко ставят задачу спроектировать SLI для тех компонентов, которые они поддерживают. Более или менее понятно, какие SLIs следует применять для пользовательских сервисов и как их рассчитывать. Однако для инфраструктурных команд попытка внедрить SLI сопряжена с рядом сложностей. Далее я расскажу несколько историй об этом и поделюсь выводами, к которым я пришел.

После прохождения одного из серии собеседований на SRE мне анонсировали, что на следующем будут задачки про SLO/SLI. Задач не было, но в ходе подготовки я сделал тематический конспект нескольких материалов, посвященных этой теме. Возможно, он будет вам полезен.

Понятно, что основной источник информации по теме – это Google SRE Book, но книга была опубликована давно, и мне было интересно, что по этой теме есть нового. В основном конспект основан на четырех материалах от Google: Implementing SLO, Art of SLOs (slides), SLO Document, Setting SLO Step by Step. Впоследствии я дополнил их несколькими интересными идеями из выступления Ивана Круглова.

Буду рад замечаниям и дополнениям.

Несколько лет во французском облаке Scaleway у меня крутилась виртуалка на Debian 10 с LAMP-стэком. После того, как я переоборудовал свой десктоп под homelab, было решено перенести эту виртуалку туда и заставить работать под ESXi 7.0. Понятно, что сделать это можно было бы вручную путем переноса конфигов. Но там много чего хостилось, и я уже не до конца помнил, что именно, поэтому в приоритете были варианты с выкачиваем образа всей машины.

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

DevOps-практики, как известно, требуют освоения длинного ряда инструментов, и если с каким-нибудь git можно экспериментировать практически на любой машине, то Nexus или Jenkins надо ставить на сервер. Они требовательны к ресурсам, и бесплатным t2.micro на AWS не обойтись. Конечно, можно получить 3 month trial от Google Cloud, но он потребуется позже для игр с managed Kubernetes. Так что я решил сделать из своего десктопа homelab. Дальше о том, что я сделал, с какими проблемами столкнулся и как их решил.