Pull to refresh
92
Karma
0
Rating
Dmitry Stolyarov @distol

Пользователь

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

Простите, ни по фичам ни по расчетам я ничего точного не смогу ответить. Это было слишком давно и слишком неправда. Актуального анализа продуктов просто нет.

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

Он-колл саппорт был всегда нашей core competency. Мы умеем всего две вещи – uptime и delivery. И первая из них требует, в том числе, он-колл. Подскажите, вы просто текстовую транскрипцию проглядывали? Или видос смотрели? Хотя я не помню о чем говорил, если честно. Давно было.

Микросервисы: размер имеет значение, даже если у вас Kubernetes

Давайте начнем с начала. Один микросервис это никак не одна фича. Один микросервис это одна продуктовая команда. Ну и на этом можно закончить, пожалуй.

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

Конечно и считали и думали. В целом мы всячески стараемся все покупать и ничего не делать сами. Из очевидного:


  1. В OpsGenie нет многих важных для нас фич.
  2. Для нас это core competency.

Как правильно сделать Kubernetes (обзор и видео доклада)

Мы используем для управления всеми нашими кубами, а это 170+ кластеров. Плюс уже есть некоторое количество внешних пользователей.


Я бы сказал так. С поддержкой от Флант он на 100% production ready. Без поддержки – пока сложно оценить, но если в компании есть нормальная экспертиза по кубам – думаю да, production ready. Если же совсем никто и совсем ничего не понимает...

werf vs. Helm: корректно ли их вообще сравнивать?

Если кратко, и не придираться к мелочам – абсолютно согласен.


Тут нужно понимать, что мы часто видим вопросы в духе "в чем отличие werf от helm" или "зачем werf, если есть helm". Стараемся объяснить как можно проще тем, кто входит в тему.

Что же такое GitOps? Его свойства и недостатки

Привет. Около 10 лет я всячески пытаюсь использовать и продвигать immutable-инфраструктуру. Из публичного, самое старое, что я сходу смог найти вот: https://youtu.be/mT5U862_ydU. Видео чуть глубже. Ну или, по крайней мере, я пытался сделать его чуть глубже.

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

В данном случае – через NATS идет индексация в Elastic, если я ничего не путаю. Но вообще, мы исторически используем NATS как основную шину связи между нашими микросервисами, через которую летают все "общие" объекты. Но тут важный момент, что вся система "инцидент менеджмента" — для нас это только один микросервис, пусть и состоящий из многих компонентов (куча разных входящих API-шек, обработчики, воркеры разных сортов, интерфейсы разные — их, тоже можно было назвать микросервисами, но у нас они лежат в одном репе, катаются всегда вместе и версионируются вместе — так сильно удобней при нашем размере команды разработки), но есть и другие наши внутренние системы, с которыми связь по NATS'у. Например, эта система ("инцидент менеджмента") является первоисточником для всех инцидентов, и соответственно она валит информацию по инцидентам в NATS, а некоторые другие микросервисы подписываются на эту информацию (и могут держать у себя реплицированную копию данных). Благодаря этому функционалу, например, у нас в тикетах показываются статусы связанных инцидентов… но это долгая история и совсем не о том.

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

Логика обобщена и сведена всего к двум видам связей "группировка" и "причина", соответственно в любом алерте мы можем указывать любое количество аннотаций одного из четырех типов:


  • group_for – настоящий алерт является "папкой" (на самом деле оно граф, но не суть) для алерта, указанного в значении.
  • grouped_by – тоже самое, что предыдущее, только в обратную сторону.
  • cause_of – настоящий алерт является причиной для алерта, указанного в значении,
  • caused_by – тоже самое, что предыдущее, только в обратную сторону.

Соответственно у алерта получается пачка аннотаций следующего вида (xxx и yyy – просто имена связей):


annotations:
  cause_of/xxx: "TriggerName,label=val1,label2=val2"
  grouped_by/yyy: "AnotherTriggerName,label2=val4"

Дальше уже из этих штук строится граф, а из графа пытаемся искать root-cause.


Дальше вопрос, где эти аннотации лежат. Варианта два:


  1. Прямо сразу в самом алерте. Если это Prometheus – вполне работает. Соответственно сразу с алертом лежат известные в нем возможные связи.
  2. В системе мониторинга есть механизм входного ремаппинга. Мы указываем выражение на mql и дальше говорим, что всем алертам, подходящим под это выражение, проставить такие-то аннотации (там можно и много чего другого менять, но в том числе и вот это). Эти правила лежат в отдельном git'е в достаточно логичной структуре, разбитые по проектам. Вместе с ними же лежит и документация по проектам (см. выше).

Дальше, соответственно, всем что можно лежит в алертах. Все что надо кастомное налепить – лежит в конкретном проекте.

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

Там достаточно типовой стек и достаточно типовая, по современным меркам, архитектура. Более менее полно ответить на этот вопрос в одном сообщении – боюсь просто невозможно. Но я попробую...


Сейчас там – Redis, MySQL, NATS, Elastic и пачка микросервисов на RoR. Redis используется для "горячих" очередей, в MySQL хранятся все данные, в том числе и архив. Elastic используется для поиска и аналитики. Все сделано специально максимально просто, но с возможностью upgrade, когда понадобится. Например, когда возникнет реальная потребность, Redis'ы достаточно просто заменяются на kafka – это решает и вопрос надежности и вопрос масштабируемости очередей, обработчики (как и все другие сервисы на RoR, они все stateless) у нас и так масштабируются (правда надо будет локализовать данные и кеш, но это детали). Архивные данные из MySQL очень просто убираются в Cassandra, а вот с горячими данными (по открытым-прямо-сейчас алертам и инцидентам), у нас есть завязка на транзакции в MySQL – и тут просто не получится, но мы знаем целую пачку абсолютно рабочих workaround'ов, в целом все сводится к тому, чтобы локализовать обработку некоторых событий по одному проекту в одном процессе, что позволит обойтись без потребности синхронизации и локов в БД, тогда Cassandra подойдет и для горячих данных.


Все компоненты живу в Kubernetes, развернутом по железу в OVH. Statefull сервисы используют local storage (и, соответственно, прибиты гвоздями к нодам).

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

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

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

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

Мы знаем о двух возможных подходах к этому вопросу:


  1. В момент поступления алерта запустить какую-то автоматическую проверку. Грубо говоря, если сервис не отвечает, автоматом запустить tracerout с нескольких точек.
  2. Всегда запускать трейсроут и если он не проходит – слать алерт, но этот алерт делать с низким severity (грубо говоря, debug). Дальше остается в основном алерте удобно и наглядно показывать дебажные.

Технически, у нас реализована поддержка обоих подходов.


  • В первом случае в JSON-алерт достаточно указать URL в специальной аннотации и он будет дернут и подтянут к инциденту при его поступлении. То есть если нужно сделать tracerout, то пишем на чем-то простейший сервис, которому GET-параметром передаем IP, а он возвращает трейс, и дальше ссылочки на эту штуку добавляем в алерты.
  • Второй кейс можно сделать по-простому, просто показывая в любом алерте соседние из проекта (и это у нас сделано давно), но по-хорошему показывать только действительно связанные. Для этого у нас совсем недавно была окончательно доделана поддержка "графов" – у алерта мы можем указать сколько угодно аннотаций caused_by, соответственно, если у нас горит два алерта, один о недоступности сервиса, второй о том что он трейсится (скорей, что не пингается, но не суть), то они автоматом объединятся в один инцидент.

Пока что получается так, что мы первым способом практически не пользуемся. А второй способ, наоборот, используется все больше и больше.

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

  1. Можете подробнее рассказать как у вас работает документации по событиям? Судя по скриншоту — это некий гитлаб. Правильно понял, что к каждому событию привязывается ссылка на гитлаб на основе лейбла или наборов лейблов события? Или дежурные сами выполняют поиск по гитлабу и ищут подходящий к событию документ?

У нас есть "язык запросов" (mql) к системе, который позволяет искать инциденты по значениям их лейблов и аннотаций. В документации указывается mql и ко всем инцидентам, подходящим под запрос, добавляется документация.


Чтобы было понятно, процитирую примеры из нашей внутренней доки по mql:


  • project = tfprod — инциденты по проекту tfprod.
  • project =~ foo and ~trigger='disk-usage' — инциденты по проектам foo* с триггером disk-usage.
  • (project = "foo" or project = 'bar') and trigger = 'cpu-usage' and ~server != gitlab-runner — инциденты проектов foo и bar с триггером cpu-usage, но исключая те, у которых сервер gitlab-runner.
    • Можно переписать через регулярное выражение: project =~ "(foo|bar)" and trigger = 'cpu-usage' and ~server != gitlab-runner
  • ~node = * — инциденты, у которых присутствует лейбл node (с любым значением).
  • issue = 222222 and team = b — инциденты по тикету 222222 в команде B.
  • user =~ Иванов — инциденты, назначенные (или предложенные к назначению при передаче) на пользователя с именем, фамилией или почтой, содержащей Иванов.
  • summary = "something bad happened" OR description =~ "wtf"
  • source = okmeter AND severity <= S3 — поиск инцидентов okmeter с уровнем severity меньше или равным 3 (найдётся S1, S2, S3).
  • @summary = 'hello' OR @ip = * — поиск инцидентов, у которых в хотя бы одном алерте summary равен hello или есть аннотация ip.
  • alerts_count >= 10 — поиск инцидентов с количеством алертов больше или равным 10.

Представляем werf 1.0 stable: при чём тут GitOps, статус и планы

Я открыл главную и кажется понял, в чем проблема. У нас там большими буквами в самом верху написано "CLI tool to construct CI/CD pipelines". Это полный провал с нашей стороны. Должно быть так: "CLI tool to use in your CI/CD pipelines`".

Представляем werf 1.0 stable: при чём тут GitOps, статус и планы

Привет.


А поясни, плиз, при чем здесь "travis, circleci, gitlab ci до argocd и teckton pipelines"? У нас нет вообще ничего про CI часть и никогда не будет.


Есть задача: "вот есть реп, нужно сделать, чтобы в кубе было тоже самое, что в репе". Привести kubernetes в состояние с git. Чтобы это сделать нужно, всего то, вызвать docker build, docker tag, docker push и helm install. В этом смысле – конечно, перекрывается. Ну а дальше много нюансов.


Что касается tekton и, вцелом, интеграции с другими CI-системами. Сейчас у нас есть два пути – штатная поддержка gitlab ci и возможность использовать что угодно через переменные окружения, есть только важный момент, что мы сейчас ограничены работой на одном хосте (см. в статье выше). Прямо сейчас мы пилим поддержку Github Actions. Явная поддержка Tekton обязательно в планах, но несколько позже, пока ничего не могу сказать по срокам

Использование werf для выката комплексных Helm-чартов

Спасибо за вопрос. Он возникает уже не первый раз, значит требует подробного ответа.


Никак не относимся. Мы не пробовали ни Argo-CD ни Flux – хотя они и решают в целом ту же область задач, но они это делают по-другому, используя чуть другие подходы.


  • По Flux лучше всего цитировать их собственную доку:


    What Flux does

    Flux is most useful when used as a deployment tool at the end of a Continuous Delivery pipeline. Flux will make sure that your new container images and config changes are propagated to the cluster.

  • По ArgoCD – я могу ошибаться, но это в первую очередь конструктор пайплайнов.


  • Werf же старается не решать вопросы CI, предполагая, что есть некоторая внешняя CI-система (Gitlab CI, Jenkins, etc), в которой описаны пайплайны, и первичная задача в werf "синхронизировать" состояние Git c состоянием Kubernetes, а именно: собрать и пушнуть образы, применить манифесты для Kubernetes. Причем сделать это удобно и гарантировано.



Почему так? Ну во-первых по историческим причинам. А во-вторых – у меня (как у "владельца продукта") есть следующий взгляд:


  1. Если вы используете Gitlab CI – у вас уже есть "Pipeline as a Code". Github запустил Github Actions, и когда станут доступны self-hosted runner'ы (они анонсированы, будут бесплатно) – получается, что в Github тоже появляется удобно сделанный "Pipeline as a Code". Что еще нужно кроме Gitlab и Github? Ну еще есть Bitbucket и пока что там все сильно хуже, но они подтянутся (или умрут) и этот вопрос тоже будет решен.
  2. Для по-настоящему эффективной работы функционал CI должен быть плотно проинтегрирован с SCM и с управлением задачами: должна быть двух сторонняя связь. В идеале – в задаче мы должны видеть конечный результат (выкаты связанных MR/PR, проходят ли тесты по ним и пр.). То есть это не простое автозакрытие задачи при принятии, а сквозная видимость в обе стороны (Issue <-> MR <-> Pipeline). Это означает, что CI фактически должен быть частью SCM/трекера. И именно так происходит в Gitlab и Github. То есть большая часть пользователей будет с удовольствием использовать или Gitlab или Github, которые будут решать все три задачи под ключ и надо ориентироваться именно на это. Плюс я думаю Atlassian подтянется и доделает свой стек, и там тоже будет 3-in-1.
  3. Мир сложный, и сколько людей – столько мнений. Мне очень нравится, в этом смысле, философия Unix, и, хотя werf это и интеграционная утилита (мы используем и helm и docker), мы все таки решаем одну основную задачу: "синхронизация Git c Kubernetes". Соответственно, если по каким-то причинам вам удобней Jenkins (у которого, кстати, Pipeline'ы тоже можно в SCM хранить, пусть и менее элегантно), или любую другую систему – да пожалуйста, werf это идеальный вариант для вас. Это просто консольная тула, которая синкает Git-комит с Kubernetes'ом. При чем оптимизированная для работы под управлением CI.

Таким образом, да – werf, сам по себе, не реализовывает в полной мере GitOps. Но в сочетании с любой "Pipeline as a Code" тулой, связка в полной мере решает этот вопрос. И будучи простой консольной тулой werf дает гораздо большую гибкость. Мы на сайте написали: A missing part of a CI/CD system.


Сейчас мы находимся на финишной прямой к выпуску 1.0 stable. Сразу после этого у нас есть Milestone, который мы называем "поддержка TOP10 CI-систем". В рамках этого Milestone мы хотим написать практические руководства о том, как правильно использовать werf под наиболее популярными CI системами (плюс сделать удобную поддержку, так же как это сейчас сделано для Gitlab). Мы посмотрим, возможно одной из этих систем будет Argo CD.

Kubernetes 1.15: обзор основных новшеств

В настоящий момент мы ставим на новые кластера 1.11 и обновляем все существующие тоже до 1.11. На глаз: примерно половина на 1.11 и вторая половина на 1.10 и 1.9. С одной стороны – все норм и все работает, поэтому не форсируем, с другой стороны – есть очень большая пачка расширенных фич, которые мы не можем использовать и это нас очень расстраивает (например, ipvs и kubelet dynamic config мы до сих пор не можем использовать, ну и куча еще всего).


Однако, мы решили форсировать этот вопрос и прямо сейчас готовим обновление 1.11 -> 1.13 (за одну операцию через две версии, там есть нюансы, но в целом так можно), должны закончить на этой неделе. И на следующей будем делать обновление 1.13 -> 1.15. Под "делать обновление" в нашем случае подразумевается проработка на тестовых стендах и подготовка инструкций для наших DevOps-команд. Сейчас мы поддерживаем три способа инсталляции: kubeadm (bare metal и все виды простых VM), kops (AWS, GCE) и aks (Azure).


В целом, буквально через несколько недель, планируем выйти на следующую политику:


  1. Не позднее чем через месяц после релиза мы должны:
    • ставить новые кластера уже на эту версию,
    • иметь возможность обновить любой из существующих кластеров на эту версию.
  2. Мы поддерживаем кластера не более чем трех последних версий (с выходом 1.15 это будут 1.12, 1.13 и 1.14) и если кластер старше – мы форсируем обновление (даже если фичи не нужны – все равно требуется обновление).

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

Микросервисы: размер имеет значение, даже если у вас Kubernetes

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

Information

Rating
Does not participate
Works in
Registered
Activity