Comments 11
Сколько людей? И еще, если Яндекс падает, вы тоже падаете?
Баги. Ну, смотря чьи баги. Ответственность за баг заканчивается фиксом. Если есть облачный провайдер и он заложил багулину в свой сервис, тут вариантов нет – это ответственность провайдера. Если это опенсорс, который я у себя развернул как self managed сервис, тут два варианта – я могу завести ишью, а могу пулл реквест. Работает и так, и так. Другое дело, что кто-то должен на нашей стороне драйвить эту багу. Чаще всего тикет заводит SRE продуктовой команды, так как он обладает самым глубоким контекстом – как появляется, как повторяется, как проявляется, айдишники, метрики, трейсы. А мы, в случае необходимости, можем эскалировать или дать helicopter view. За баги в наших сервисах отвечаем мы.
С администрированием два варианта. Если команда с низким уровнем зрелости, это делает техплатформа. Если команда с высоким уровнем зрелости, у нее есть свои SRE/DevOps, зачем нам выступать прокси? Мы даем на инфраструктурный проект в Git права, пусть управляют, это же их продукт в конце концов. В любом случае, мы не являемся SRE/DevOps-as-a-Service, потому что мы не обладаем контекстом. Но мы придем, в случае однозначных поломашек, например, если наша меш пинговалка выявит хитрые сетевые ножницы, если будет недоступен NLB ну и еще ряд сценариев, когда наши status boards разукрашены красным.
Руками (и головой, чего уж там) работают SRE и DevOps. SRE отвечают за среды. Создать, изменить – инфраструктурный код сам себя не напишет. За алерты – у нас огромное число специализированных каналов, чтобы любой заинтересованный мог подписаться под нужное и не испытывать давление информационного шума. Если алерт стандартный, там же будет прописан ранбук: пойди туда, сделай то. Сначала SRE «ставит глазки», что увидел и взялся, потом отписывается после выполнения. Если нестандартный, то может сам отреагировать, может дежурного DevOps призвать. Плюс консультации. DevOps ведут разработку всей этой инженерии. Это огромная проделанная работа. Для cloud managed мы взяли каждый сервис, посмотрели метрики, которые отдает облако, описали SLI/SLO, сделали дашборды, алерты, потом избавились от false positive алертов. Потом каждый постмортем, при необходимости, рефакторили. Для self-managed сервисов – добавьте еще архитектурное планирование, деплоймент, HA, нагрузочное, краш-тесты, по возможности self-healing.
Команда имеет two pizza team size.
Смотря как упадет. Если в пределах одной зоны, то business critical сервисы будут работать. Если совсем весь регион, то куда мы денемся. Но события такого рода случаются штучно. За полтора года я помню один инцидент масштаба всего региона.
Теперь возьмем систему, состоящую из трех компонентов. Если отказ любого приведет к отказу всей системы, то вероятность отказов суммируется,
А если система из 2000 компонентов, то вероятность отказов — 100%? А если из 4000, то 200%? На самом деле, если у вас 3 компонента в доступностью 0,9995, то доступность всей системы — 
, что (по совпадению) равно 0,9985. Но если компонентов тысяча, то по вашей формуле будет 0,5, а на самом деле — 0,6045
Конечно, у нас есть ИБ. У них есть инструменты, которые находят всякое разное в коде и заводят задачки продуктовым командам. Есть политики про публикацию ресурсов наружу, так что мы контролируем сущности в облаке с публичным адресом. Есть совсем очевидные политики про табу на крэды в коде, для этого есть Vault. В этом смысле подход к продуктам в облаке почти ничем не отличается от онпрем. ИБ использует сервис Yandex Audit Trails, но глубоко про это я не расскажу в силу удаленности от процесса.
По разделению на IaaS/PaaS сложно сказать точный процент, я сейчас открыл биллинг, там условно 15 единиц компьютов, 3 единицы постгреса, 1 единица редиса, 1 единица кафки. Но штука в том, что значительная часть компьютов окажется воркерами для кубера, а не виртуалками, где команды крутят монолиты. SaaS типа Managed service for GitLab не используем, потому что у нас есть сильная потребность управлять жизненным циклом таких продуктов в полном объеме.
Можете чуть больше рассказать про ваш интерес к этому проценту? Как вы его интерпретируете?
Озвучу свое понимание терминов на случай, если мы немного по-разному их видим: в моей голове IaaS – это виртуальные сети, компьюты и диски, PaaS – это cloud managed Kubernetes, database, message queue и т.д., а self managed сервисы – это то, что мы делаем поверх IaaS/PaaS, например, Vault, Harbor, Nexus или какой-нибудь Couchbase.
IaaS и PaaS сущности мы создаем терраформом. Для разных провайдеров в коде будет своя определенная специфика, процесс ресайза будет слегка разным, надо держать в голове специфические ограничения провайдера по перфомансу, мониторинг у каждого провайдера индивидуальный, но главное что PostgreSQL/Redis/MongoDB на выходе будет примерно один и тот же.
Можно нагрешить с вендор локом и начать использовать классные штуки, которые есть только в AWS или GCP, тогда от провайдера уйти будет сложно. Поэтому архитектурные комитеты, поэтому техрадар и диктат в тулстеке. Нам было одинаково комфортно в AWS и ЯО.
Вопрос экономии обычно сложный, потому что по-разному работает на разном объеме и задействованы не только железки, но и люди. Каждый кейс индивидуален. Поэтому и тренды меняются, то все бегут в публичное облако, то все строят гибрид, то опять приватные облака в моде.
Сегодня я хочу рассказать про переход в публичное облако
Спустя год после такого перехода, я хочу рассказать к чему это привело.
Доступность с архитектурой и UI/UX/CX – это ортогональные сущности. Было бы логической ошибкой их соединять причинно-следственными связями.
С ортогональностью согласен, но только если трактовать её в математическом смысле (скалярное произведение двух элементов пространства равно нулю). Можно иметь лучшую в мире архитектуру, но если умножить её на нулевой UI/UX/CX, то в конечном итоге и толку от неё ноль.
По поводу причинно-следственной связи – она прямая. После изменения архитектуры последовало изменение UI/UX/CX, что и привело к возникновению многочисленных багов.
Напоминаю, вам ничто не мешает обратить на эту проблему внимание коллег из соответствующих отделов.
Сделай так, чтобы оно больше не падало