— Рикардо, как ты стал SRE?

— Много лет я был обычным инженером-программистом, просто создавал продукты. И однажды начал больше специализироваться на серверной части, поскольку меня больше интересовал backend. Потом я провел пару лет в Лондоне, где впервые почувствовал разницу между Ops и Dev. На протяжении всей моей карьеры я всегда нес некоторую оперативную ответственность при создании продуктов. Я был ведущим разработчиком в Лондоне в крупной компании. Мы передали много работы на аутсорсинг, потому что были небольшой командой.

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

В то время термин DevOps начинал набирать популярность. Примерно в 2015 году я стал DevOps Engineer, но не перестал придерживаться подхода программной инженерии. Я всегда думаю: как я могу решить эту проблему, используя свои навыки разработчика? Итак, когда я начал слушать, читать и разговаривать с людьми о SRE, привлекательность подхода была очевидна. Суть SRE заключается в том, как я могу подходить к операциям как к проблеме разработки программного обеспечения. Это то, что я пытаюсь сделать уже очень долгое время.

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

— Как вы представляете надежность сегодня, основываясь на своем опыте?

— Я использую структуру SLO, хотя нам время от времени приходится ее адаптировать. Прежде чем получить определение SLO, я говорю с разработчиками продукта и представителями бизнеса. Консультируюсь с ними о бизнес-потоках или пользовательских историях, наиболее важных в нашей системе. И когда мы понимаем, что пользователь делает с платформой, размышляю, что мы можем сделать для надежности, а пользователи продолжали пользоваться нашим продуктом? Иногда это требует общения с самим клиентом.

Например, я думал о банковской системе. Обычно пользователи не возражают пожертвовать скоростью, чтобы убедиться, что средства были правильно переведены из пункта А в пункт Б. Они не так сильно беспокоятся о том, что это будет сделано за 500 миллисекунд или что-то в этом роде. Как только у нас будет эта информация, мы определим SLO для этого. Например, за последние 30 дней 99,9% моих проверок прошли успешно. Хорошо. Есть ли у нас показатели, журналы и трассировки для ее поддержки? Если нет, мы рассмотрим часть, посвященную наблюдаемости. Мне нужно включить сигналы, которые позволят гарантировать, что SLO может быть настроен.

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

— Вы постоянно общаетесь с большим количеством людей. Как выглядит ваш обычный день?

— Да. Мы строим горизонтальную команду, которая будет создавать инструменты, библиотеки и многое другое для других команд. Мы не являемся частью какой-то конкретной команды. Фокусируемся на составлении бизнес-потоков, обеспечении наблюдаемости и разработке некоторых стандартов, потому что наши услуги становятся все более масштабными.

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

— Существуют ли какие-либо инструменты, от которых вы зависите, например, средство командной строки или какой-либо язык?

— Python был общим языком, который мы использовали в большинстве компаний, в которых я работал. В последние несколько лет я использую Golang и создаю CLI или API с использованием Golang. Хотя большинство наших систем основаны на JVM на Java, Scala и Kotlin, наша команда в основном использует Python для операционной работы.

— Есть ли какие-либо инструменты, которыми вы пользуетесь каждый день, помимо этих языков?

— Да, для IaC я использую Terraform, Ansible и Chef для управления конфигурацией, Kubernetes для оркестровки и много чего еще, связанного с Kubernetes. Такие вещи, как helm, использующие GitOps с Flux или Argo CD, сервисные меши Istio. Это многие из проектов CNCF, которые мы используем в настоящее время.

— Как вы решаете, какой инструмент наблюдения выбрать?

— Вы можете выбрать комплексное SaaS-решение, что-то вроде New Relic или Datadog. Это хорошо, потому что большинство вещей уже интегрировано. Если вы используете их библиотеки и SDK, все предоставляется практически бесплатно.

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

Главная проблема — нужно переключаться между инструментами. Так, например, вы используете трассировку. Было бы полезно, если бы вы обратились к Jaeger. Затем вы идете к метрикам. Возможно, у вас есть Prometheus и Grafana. Затем у вас есть журналы, а затем вы переходите куда-то еще.

Стек Grafana с Loki и всеми их инструментами для метрик и журналов дает вам центральную опору, куда вы можете обратиться и сопоставить данные друг с другом. В общем, я двигаюсь к тому, чтобы попасть в центр управления и увидеть все, вместо того, чтобы прыгать вокруг. Иначе инженерам требуется много времени.

— Так ли важен единый источник данных?

— Даже если вы используете продукты SaaS, для ведения журналов вам нужно перейти в Elastic Cloud. Для получения метрик вам нужно перейти в Datadog или что-то в этом роде. Это очень утомительно. И затем вам понадобится помощь в сопоставлении материалов, потому что эта информация фрагментирована в разных инструментах.

Если вы сможете объединить эти вещи, вы сможете легко просматривать их. Так что это будет решающим фактором в будущем. Конечно, для этого нам все еще нужна некоторая стандартизация. Мы все еще находимся в начале стандартизации для обеспечения наблюдаемости. Но, в конце концов, в сервисах будет все.

— Говоря о создании команды SRE, что наиболее интересно?

— Одной из моих обязанностей было решить, на чем сосредоточится команда SRE. Мы определили пару моментов, которые необходимо было учесть, и мы хотели это сделать. Одним из примеров является наблюдаемость. Нам нужен кто-то, кто позаботится об этом и обеспечит нам достаточную наблюдаемость, чтобы понять, надежны ли наши системы.

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

— Есть ли у вас набор информационных панелей, на которые вы смотрите ежедневно?

— Да, вроде того. Мы собираем метрики на системном и бизнес-уровне. Показатели, связанные с бизнесом, сообщают нам, если что-то ухудшается или происходит что-то необычное. Нам нужно решить, что мы хотим создать в будущем, чтобы понять, доволен ли пользователь сейчас. Затем, конечно, мы можем наблюдать за конкретными сервисами или меньшими потоками.

У нас есть несколько внутренних хакатонов, где мы много думаем об этом, но пока нам важна максимальная простота.

— А как вы реагируете на инциденты?

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

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

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

Люди должны понимать, что время от времени, особенно когда имеешь дело с техническими вопросами, ты должен общаться с людьми о влиянии этого инцидента на бизнес. Было бы полезно, если бы у вас был кто-то, кто мог бы организовать это общение и убедиться, что что люди работают над этим и хорошо понимают проблему.

— Как вы думаете, где организации испытывают трудности на пути к наблюдаемости?

— Обычно я видел организации двух типов: с недостаточной наблюдаемостью и со слишком высокой. Когда у вас есть только метрики или только журналы, вам нужна помощь, чтобы выяснить, почему это произошло. Каждая организация проходит через это. И лучшие команды идентифицируют и говорят: "хорошо, у меня есть только журналы". Мне нужно больше информации, чтобы принимать решения получше.

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

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

— Как вы остаетесь в курсе всех новостей индустрии?

— Я слежу за техническими блогами конкретных проектов или их разработчиками, потому что они выполняют за вас тяжелую работу. Например, я подписан на OpenTelemetry, Kubernetes, Prometheus. Знакомлюсь вкратце и решаю, читать ли дальше. Еще у меня есть список интересных блогов:

— Есть ли что-нибудь в мире наблюдаемости, что вас волнует?

— То, о чем я беспокоился — это тенденция к переименованию всего, что связано с наблюдаемостью. Есть разница между мониторингом и наблюдаемостью. Но внезапно все стало наблюдаемостью. В основном это был ребрендинг множества инструментов.

Я также беспокоился о взрывном росте проектов и инструментов в пространстве наблюдаемости. Если так пойдет и дальше, мы никогда не сможем успеть за всем. Некоторые из этих проектов нуждаются в объединении, и должна появиться стандартизация. Это не значит, что не будет конкурирующих вещей. Но одно дело, если у вас есть одна, две или три вещи против двадцати.

— Был ли какой-нибудь запоминающийся инцидент, над которым вы работали?

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

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

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

— Какие два важных качества SRE-инженера?

— Пожалуйста, сосредоточьтесь на клиенте. Я все еще вижу, как многие SRE борются с этим. Я понимаю, потому что иногда это отражает организацию, на которую они работают. Бывают задачи, которые необходимо решить сейчас. Например, если вы предоставляете какие-то услуги с веб-сайта, а сайт ежедневно падает. Это одно, но другое — сосредоточиться на пользователе. И когда вы достигнете того момента, когда захотите определить, измерить и оценить надежность, всегда фокусируйтесь на пользователе.

Кроме того, есть и проблема в нейминге. Недостаточно назвать SRE, чтобы превратиться в него по-настоящему. Были системные администраторы, и их превратили в инженеров DevOps. Некоторые из них были преобразованы в инженеров SRE, но они продолжают делать одно и то же неоднократно. Они использовали скрипты bash, а теперь используют Terraform. Но в их повседневной работе ничего не меняется. Таким образом, понимание масштабов их работы и подхода к надежности или операциям должно отличаться от организации к организации.

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

С Рикардо можно связаться через Linkedin и Twitter. Он также много пишет в своем личном блоге.

История и интервью о SRE

Получите бесплатную консультацию по DevOps-услугам