Человек и машина

Итак, мое первое дежурство, и я вижу, что некоторые системы падают с завидной регулярностью.
После анализа я вижу следующее:
1. Система выступает как центральное звено, ее падение вызывает падение зависящих от нее приложений.
2. Система используется для решения задач, для которых она не предназначена (Например event sourcing система используется так же как долгосрочное хранилище событий).
3. Система была спроектирована под определенную нагрузку и объем данных и теперь она не справляется.

С ростом объемов и нагрузки можно справиться либо оптимизацией производительности и рефакторингом, либо добавлением ресурсов, если рост органичен.

Другое дело с неправильной архитектурой.

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

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

То есть старший инженер с 10+ годами в конторе и вчера нанятый младший разработчик имеют одинаковый вес голоса.

Я поставил перед собой две цели:
- Избавить нас от проблем 1 и 2 в кратчайшие сроки.
- Сделать так, чтобы этого не повторилось в будущем.

Чтобы достичь первой цели в первую очередь нужно думать по принципу win-win.
То есть не идти к разработке с operations требованием (сделайте так, чтобы ваши приложения не падали), а мотивировать их разрабатывать с reliability in mind, что в итоге будет плюсом и для всех.
Решение было простым, но потребовался административный ресурс. Я поговорил с нашим техническим директором, и мы договорились о следующем:
- Необходимый SLO ставится одной из целей в KPI команды (от KPI зависит годовой бонус)
- 20% спринта выделяется на уничтожение технического долга. Ops определяют приоритет задач, как stakeholders.
- В нашей (Ops) команде на ближайшее время 50% ресурсов уходит на уничтожение технического долга.

Для второй цели пришлось сделать некоторые манипуляции с процессом разработки.

Во-первых, общение между инженерами и разработкой как пункт чек-листа перенесли из Definition of Done в Definition of Ready. Это позволило инженерам участвовать в grooming и planning сессиях (то есть на самих ранних стадиях) разработки.
Участником от инженерной команды назначается текущий дежурный инженер. Это позволяет соблюдать определенный нейтралитет и минимизировать риск принятия неправильного решения под воздействием эмоций или дружеских отношений между инженером и разработчиком. Также нет “привязки” конкретной задачи к конкретному инженеру, и тот может спокойно идти в отпуск или на больничный.
Помимо этого перед планированием дежурный инженер и один или несколько разработчиков разрабатывают несколько PoC с использованием разных сервисов AWS, которые затем демонстрируются перед началом работ по разработке и имплементации. Наилучшее решение (то есть то, которое эффективнее всего решает данную задачу и не конфликтует с зависимостями) уходит непосредственно в разработку.

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

Например, мы решили заменить DC/OS на Fargate. Эта инициатива требует переработки всех существующих CI/CD pipeline’ов, тестирования и, как результат, - времени разработчиков.

Прежде чем презентовать Fargate как преемника контейнерной оркестрации мы проводим тренинг, где разработчики сами создают кластер и разворачивают dummy приложение на оном.

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

Я уже писал про таких SME (Subject Matter Expert) - специалистов, имеющих экспертизу в определенной области.

В контексте обмена знаниями, давайте рассмотрим первый кейс - мой любимый и ненаглядный GSMG.
Наша core команда - небольшая группа лиц, отвечающих за определенный “участок” (как это обычно бывает в стартапах).
Я отвечаю за эксплуатацию и AWS, наш бекендер лучше всего знает, собственно, бекэнд, фронтендер - фронтэнд, двое человек отвечают за маркетинг и PR, а наш “Один Всеотец” лучше всего шарит в торговле криптоактивами (с его небольшого скрипта на питоне все и началось) и диктует направление разработки.

Для того, чтобы эффективно разрабатывать и развивать нашу систему, мы постоянно взаимодействуем между собой, отдавая “авторитет” в принятии решений друг другу в контексте определенного участка.
Проще говоря, я не буду говорить нашему бекэндеру как использовать asyncio, а он не будет рассказывать мне, как конфигурировать proxy-кластер.

Нас очень мало (по количеству рук) в условиях такого масштабного проекта, поэтому обмен знаниями очень простой и работает в бОльшей части вербально - мы созваниемся, обсуждаем, приходим к выводам и принимаем решения. Что решили - быстренько документируем в базе знаний, либо в документации к приложению.
Разработчики при проектировании систем приходят ко мне за советом, как реализовать некий кейс в условиях AWS, а я консультируюсь у них по правилам балансировщика, чтобы Fargate task’и успевали подняться.

В этом ключе небольшой silo по экспертизе не мешает, поскольку разработка проекта хаотична, и Scrum головного мозга по нам не бьет.

Теперь рассмотрим другую ситуацию - моя основная работа, которая меня кормит.

В конторе есть департамент, в департаменте 5 команд - 4 команды разработки и 1 команда DevOps (хотя по факту больше Ops), в которой я и состою.

Взаимодействие между эксплуатацией (нами) и разработкой (ними) идет по сервисной модели.
То есть мы, как эксплуатация, предоставляем набор сервисов и инструментов разработчикам (AWS, CI/CD и прочие сис. админские прелести), а разработчики это настраивают под себя и разворачивают свои приложения направо и налево.

Я не могу сказать, что этот “тот самый” DevOps, который я хочу видеть, но до “того самого” у нас пока нет.

Главной проблемой такой “сервисной” модели являются те самые архитекторские решения, принимаемые разработчиками без нашего участия.

По процедуре у каждого продукта есть свой специальный чек-лист, в котором один из пунктов стоит: “Продукт одобрен одним или несколькими системными инженерами.”

Стоит ли говорить, что этот чеклист начинает отрабатываться, когда продукт спроектирован, разработан, запущен в тестовом окружении, и наша “подпись” нужна только для того, чтобы выкатить продукт в промышленное окружение?

А теперь представьте, что я изучаю продукт и вижу, что там используется та же DynamoDB для редкой обработки больших объемов данных (что, как я писал, дорого и неэффективно). Одобрю ли я такое решение? Разумеется, нет.
В итоге я оказываюсь в положении, что должен завернуть разработку и заставить все переписать, ломая весь план и архитектуру, а это - дни и недели потерянной работы.

Этого можно избежать, если члены инженерной команды будут участвовать в проектировании решения (что делается в любой конторе, где DevOps это культура, а не человек).

С этой проблемой я столкнулся сразу, как мы запустили on-call ротацию в нашей команде, и в следующем посте я напишу, как мы это дело “чинили”.

Когда мы говорим про обмен знаниями, мы подразумеваем два аспекта: документацию (knowledge base) и образование (onboarding, knowledge sharing, тренинги и прочее).

И если с документацией все понятно и прозрачно, то с обменом знаниями у людей все еще возникают недопонимания.

Вот, например, самый странный способ, подготовить новичка - вручить ему доступ к кодовой базе и документации, пусть читает.

Такой способ солидно экономит время команды, но подходит он только для опытных спецов - иными словами, такой onboarding подходит для medior/senior/principal уровня, когда человек знает, как и что делать, и ему надо узнать как все сделано в условной конторе/команде.

С junior уровнем, понятно дело, все иначе. И пусть и есть садисты, которые выпускнику дают кодовую базу на изучение, в большинстве (я надеюсь) случаев, к человеку привязывается ментор, который готовит новичка, используя тот же shadowing/reverse shadowing.

Однако рассмотрим ситуацию с другого угла, когда нужен обмен знаниями не внутри команды, а между командами.

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

Классический пример из опыта - разработчики решили использовать DynamoDB для batch обработки событий. Чего разработчики не знали, так это того, что DynamoDB как решение для batch обработки стоит слишком дорого, но всплыло это уже не в качестве вопроса (“Эй, Томас, мы тут думаем использовать динаму, потому что она очень шустрая. Нам нужно обрабатывать 10 000 событий в минуту, как нам лучше сделать? Подойдет ли она?”), а в качестве проблемы (“Эй, Томас, мы тут сделали Динаму, но она почему-то выплевывает нам 400 Throttling, как нам заставить это работать?”).

Не углубляясь в детали - DynamoDB имеет определенные лимиты на API вызовы, и 10 000 операций в минуту (допустим запись), это около 170 вызовов в секунду, что приблизительно 0.765 USD в час или 558.5 USD в месяц.

Чтобы вы понимали - это очень дорого.

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

Съездив в Москву и выступив на форуме, я был приятно удивлен интересу к теме моей презентации (Кто не помнит - она была про миграцию в Амазон).

Я прекрасно понимаю, что “большая тройка” облаков давит на русских инженеров тремя факторами: ценой, законодательством и риском.

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

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

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

А также спасибо @stekov_me, @SinTeZoiD, @mo1seev, @count0ru, @aftertime и @Shader444 за очередные веселые посиделки. 😉

Но не все мне рассказывать о своих веселостях. Ожидайте контент на тему knowledge sharing.

К коллегам по цеху (не важно в вашей команде/компании или вне) нужно относиться с уважением.

Взаимное уважение дает нам полезное взаимодействие (collaboration) и минимизирует риск конфликтов (нет “токсичности” - нет конфликтов).

Благодаря взаимному уважению живет и здравствует OpenSource.

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

Но порой я вижу такой “контент”, от которого, кроме как смеха, другой реакции выдать не могу.

Если вам, мои дорогие читатели, нечем заняться, и вы, как это обычно бывает, задумались о бренности бытия - вашему вниманию шикарная статья на тему Docker: https://habr.com/ru/post/445914/

Безотносительно компетенций автора статью можно разобрать на “мемесы”. Я, словно 10-летний тролль-сношатель-чужих-мамок, хихикал буквально от каждый строчки.

Разбора статьи, конечно, не будет. Нечего разбирать.

Если автор оригинальной статьи увидит этот пост, я с удовольствием обсужу его труд с ним.

Уважайте друг друга. Всем любви.

Я стараюсь не касаться тем политики, гендерного неравенства, толерантности и прочих “с жиру бесятся” и “проблемы первого мира” (не в этом канале, а вообще по жизни).

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

Для начала оглянусь чуть назад в историю, а именно в 2014-ый год, когда учеными из ESA была совершена посадка зонда “Розетта” на комету 67P/Чурюмова-Герасименко.
Доктор Мэтт Тейлор, после успеха миссии давший интервью, надел тогда рубашку с полуголыми нарисованными женщинами (парень вообще полный рок-н-ролл, поищите его изображения в интернете), чем вызвал фурор.

Стоит ли говорить, что все внимание общества было приковано не к прогрессу команды ученых, а к рубашке одного из ее членов?

Не скажу сейчас всех подробностей скандала, помню лишь, что доктору пришлось публично извиняться за то, что он надел “сексистскую” рубашку.

Теперь вернемся обратно в наше время.
Вторым по популярности изображением (первое это изображение собственно самой черной дыры) стало восхищенное лицо доктора Кэти Боуман, и появились новостные вырезки: “Доктор Кэти Боуман, лидер команды ученых […] вот ее выражение лица, когда фотографии были получены.”

Я восхищаюсь успехами женщин в области бизнеса, науки и спорта (нет, я не феминист), поэтому я искренне обрадовался за девушку - далеко не все в 29 лет имеют такие достижения.

Чуть позже стали всплывать очерки о неком ученом Эндрю Чейле, который, по словам этих ваших интернетов, написал 850 000 строк кода из 900 000, в то время как доктор Боуман написала только 2500 (а то ваши тимлиды больше кода пишут, лол).

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

Интернет в свою очередь отреагировал как: “ну подумаешь, он больше написал, Кэти тоже молодец, ну че вы ребята, успокойтесь”. Смешно смотреть (особенно смешно смотреть такие дискуссии на LinkedIn).

Поступок Эндрю вызывает исключительно уважение. Настоящий ученый - “творец” - должен быть скромен, ведь он делает то, что делает не для популярности, а для прогресса человечества.

Но мне интересно - а если бы было наоборот? Как бы отреагировала общественность, если б фото Эндрю пестрило по сети, а затем выяснилось, что основную работу выполнила Кэти?

Впрочем, даже знать не хочу.

Я все пишу о разных подходах, процессах и прочей водичке, но вроде ниразу не писал про инструменты.

Чтобы вы понимали - моя работа не только стрелочки соединять и читать документацию. Иногда нужно работать “ручками”. Когда код писать, когда шаблоны для ресурсов, когда пайплайны пилить или конфигурацию серверов - стандартная работа любого инженера.

Расскажу сегодня о моих любимых инструментах.

Что касается IDE: PyCharm (Pro) с плагинами aws-toolkit и Cloudformation, Goland, для работы с БД - DataGrip. Когда приходится ковыряться в Scala - IntelliJ IDEA Ultimate с плагином Scala. Для “быстро посмотреть, поправить” - VS Code с тучей разных плагинов.

По работе с облаками - aws-shell, pure Cloudformation (пишу на YAML), SAM, ecs-cli, cfn-skeleton (позволяет очень быстро набросать скелет шаблона), Terraform для личных проектов, Packer.

Стрелочки соединяю в Lucidchart и draw.io.

Документация - в кодовой базе Python docstring, Markdown. Остальное идет в Confluence (на текущей работе полный стек Atlassian: JIRA, Confluence, Bitbucket).
Амазоновскую документацию держу локально на флешке в PDF (Cloudformation, ECS, EC2, RDS, DynamoDB, Lambda, API Gateway, SQS, IAM, etc), на случай, если нужно поработать без доступа в сеть.

Для набросков купил себе тетрадь формата А4 за пару евро в магазине рядом с домом. Всякие стикеры не понимаю, равно как и “умные” блокноты по 30 евро с молескинами.

Вот в целом и все.

Есть конечно и прикольные инструменты (для облака), типа Troposphere или GoFormation, но я привык к стандартному подходу и не очень горю желанием делать unit тесты вокруг шаблонов.

Если будут вопросы, пишите.

Напоминаю, что на DevOpsForum.ru можно попасть со скидкой по промокоду #Friends.

Дорогие читатели, у меня для вас небольшая новость.

20-ого апреля я буду выступать на конференции DevOpsForum 2019 (https://devopsforum.ru).

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

Мой доклад будет посвящен миграции в публичное облако Амазона.
Если хотите пересечься на кофе-брейке - смело пишите.

По промокоду #Friends можно выбить себе скидку на билет.

Говоря о фундаменте, будь то первичное проектирование (что бывает перед запуском проекта или миграцией) или повторное (как в моем случае), важно учитывать важность так называемого MultiAccount Strategy (MAS).

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

Идея разбивать структуру по определенным группам или OU далеко не нова и пришла к нам еще во времена зарождения LDAP, получив полноценное развитие в Active Directory.

Реализация MAS в AWS подразумевает то, что мы создаем иерархию OU, создаем необходимые аккаунты и прикрепляем их к OU.

На данный момент существует две основной модели внедрения MAS:
- По окружению (prod, test, staging, dev)
- По проектам/отделам (Project A, Project B, Sales, Marketing, etc)

Обе модели можно комбинировать. Например у нас может быть OU на каждый проект, а в нем будут аккаунты по окружениям.

Для чего используются разные аккаунты? В основном для двух целей: безопасность и биллинг. Так же можно «обходить» лимиты или наслаждаться халявой Free Tier.

По биллингу все просто - если у вас один аккаунт, то довольно сложно разобраться, какое приложение или проект «тратит» больше денег, и нужно анализировать это с помощью resource tags и resource groups, в то время как MAS предоставляет консолидированный биллинг, и можно посмотреть, какой аккаунт обходится вам во сколько денег.

Что касается безопасности, то MAS создает дополнительный барьер. Если вы по невнимательности дали права IAM пользователю ec2:*, то эти права будут распространяться только на конкретный аккаунт и не затронут «соседний».

Это только вводная информация по MAS, эта тема довольно большая и сложная в реализации, так что если у вас есть вопросы по различным use case’ам - вы знаете, куда писать.

Мигрировать со своих мощностей в Амазон трудно.

Еще сложнее - пересоздать фундамент внутри.

И еще сложнее сделать это с помощью инструментов Infra-as-Code.

У Terraform, не смотря на большой (на мой взгляд) недостаток - невозможность отката изменений - есть конкурентное преимущество, позволяющее импортировать существующий ресурс. У Cloudformation такого нет, равно как и нет возможности пересоздать или изменить ресурс, если тот был модифицирован или удален в консоли.

Вызвано это не техническими ограничениями. Амазон, как компания с ОЧЕНЬ агрессивной бизнес моделью, стремится навязать вам не только использование своих ресурсов, зачастую жестких vendor lock’ов (одна только DynamoDB чего стоит), но и свою модель проектирования и управления облаком.

Иными словами, если вы начали создавать свою инфраструктуру через консоль, то и делайте это через консоль. Начали с IaC и Cloudformation - придерживайтесь строго этой модели, иначе никак.

Последняя “фича” drift detection, отслеживающая разницу между state’ом CFN и фактическим состоянием ресурсов, лишь предупреждает вас об отличиях. Сделать с этим ничего нельзя, нужно ручками идти в консоль и править там.

По уму приходится делать следующее: запрещать все API вызовы, кроме Get (читай - ReadOnly) для всех ролей, кроме service role для CFN, долго объяснять разработчикам, почему увеличение размера ASG на 1 экземпляр должно проходить через относительно длинный CI/CD, и что еще важнее - навязать это среди своей команды.

2019-ый год определенно будет для меня интересным.
В целях: пересоздать фундамент с нуля (MultiAccount strategy + Cloudformation + переезд с сервисов на ЕС2 на managed) и получить AWS Solution Architect Professional.

Причем я еще не знаю, что из этого сложнее.

Как вы догадались, я в отпуске.

Скоро вернусь в рабочее русло и расскажу пару интересных вещей.

P.S. Рим - лучший город на земле (после Москвы, разумеется).

По очевидным причинам я не слежу за рынком труда в сфере ИТ в России.

У меня нет никакого понимания, какой необходимый уровень требуется, какие инструменты сейчас в “тренде”, и, разумеется, какой нынче ценник.
Когда я познакомился с русской DevOps “тусовочкой”, а @SinTeZoiD затянул меня во всякого рода чатики, у меня возникли довольно противоречивые чувства.

Получилось, что сферический DevOps в вакууме использует следующие инструменты:  SaltStack, Kubernetes, Go, Prometheus. Некоторые в довесок к этому еще варятся с Ceph, Python и Ansible.

Довольно забавно сравнивать их с нидерландскими итшниками - тут в обиходе Puppet/Ansible, облачные провайдеры (по очевидным причинам), тот же кубер с прометеем, и, прости Господи, Ruby.

Если открывать и листать HH.ru, то данные будут другими - тут весь ассортимент на любой вкус и цвет, но “одинаковость” инструментария наталкивает на мысль, что коллеги ходят на одни и те же митапы, слушают одни и те же доклады и, как результат, используют одни и те же инструменты.

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

Если кто-нибудь объяснит мне феномен с “одинаковостью” - буду крайне признателен.

DC/OS в версии 1.11 добавил поддержку Kubernetes.

Для тех кто не в курсе - DC/OS это уровень абстракции над Mesos, и в качестве контейнерной оркестрации там используется Marathon.
Разумеется, DC/OS проигрывает в битве с Kubernetes, и не важно почему: хайп, Google, you name it - причин там очень много.

Поняв, что конкурировать с кубером в поле контейнерной оркестрации нельзя, Mesosphere сделала следующее. Выпустила распрекрасный блог пост о том, что “Кубер нам не конкурент, мы вон, смотрите, даже внедрили его поддержку”. (https://mesosphere.com/blog/the-docker-vs-kubernetes-vs-apache-mesos-myth/)

Любой куберовод задастся вполне логичным вопросом: зачем мне поднимать кластер DC/OS и ставить на него Kubernetes, когда я могу сразу поставить Kubernetes? Вопрос вполне себе валидный.

В свою очередь DC/OS помимо оркестрации предлагает запуск различных сервисов. То есть непосредственно на фреймворке Mesos вы можете запустить кластер Kafka, балансировщики, ElasticSearch, Jenkins, Cassandra… Да в целом много всего. Самое смешное, что это все еще контейнеры запущенные на уровне Marathon’а, но пользователь видит их как отдельные сервисы.

Штука, на самом деле прикольная. Ну а что? Получается такой себе cloud provider на коленке. Хочешь какой-то сервис (будь он stateful или stateless) - выбери из каталога, да установи. Если его в каталоге нет, то запакуй его в “правильном” формате да и выкати. Удобно.

Вот только у Кубера есть операторы, которые (как я понял из документации) делают ровно тоже самое.
Посему вопрос остается прежним. Зачем нужен DC/OS?

ну что, ребятки,заждались?!
Уже завтра второй митап от @aws_ru, и доклады не просто от сертифицированных специалистов, а от специалистов из самого АМАЗОНА!
На этот раз митап пройдет в КРОКЕ (за что им отдельное и большое спасибо!) Докладов будет 2, но зато каких!

«AWS Firecracker»
От Василия Пантюхина
Solution Architect
Amazon Web Services EMEA

«Все,что вы хотели знать о сервисах Машинного Обучения и ИИ на AWS: вопросы и ответы»
Денис Баталов
Tech Leader, ML & AI
Amazon Web Services EMEA

Обещаю вам еще спецов из AWS, пиццу, бесплатную парковку (по заранее оставленным контактам).
И ламповую атмосферу - потому как ТРАНСЛЯЦИИ НЕ БУДЕТ!!!

Кто хочет успеть к нам - регистрация на meetup.com
Вход по пропускам, потому что это главный офис Крока, и если ваша фамилия в паспорте не @Stekov_me, а вы зарегистрировались именно так - то могут и не пустить)

Регистрация на https://www.meetup.com/aws-ru/events/259297465/

Кто будет в Москве и хочет послушать много интересного про AWS - зарезервируйте время, поскольку трансляции не будет. (А вот AWS в регионе Россия обязательно будет)

Поступок Splunk Inc. низок и бьет в первую очередь по доверию к большинству западных вендоров (если это доверие вообще осталось).
Так же глупо, как выход некоторых азиатских компаний с европейского рынка из-за GDPR.

Чем разобраться в вопросе и найти решение - включаем “РКН” и лочим все подряд.

Добавим к этому, что некоторые ИТ продукты русского производства на порядок лучше заграничных конкурентов (русский инженер всегда сильнее, не забываем) и просто ждем, пока крупнякам типа Яндекса и ко надоест монополизировать сектор России и СНГ и захочется двинуться “налево” по географической карте.

Вопрос не 10 лет, но тем не менее огорчает, как ИТ управленцы не заглядывают чуть дальше своего годового бонуса.

На обеде с коллегой обсуждали годовые цели для нашего департамента (их выполнение прямо влияет на бонус).

Из года в год цели выставляются практически одинаковые. Две основные - uptime (в многочисленных девятках) и список “фич”, которые мы должны “доставить”.
Не смотря на то, что цели выставляются по модели S.M.A.R.T., они не всегда таковыми являются. Я не хочу вдаваться в подробности внутренней кухни - просто приметим, что достижение обеих целей (uptime и feature delivery) одновременно практически невозможно, либо требует титанического труда всех департаментов (бизнесовых в том числе).

На выходе имеем, что наш департамент либо “доставит” нужное количество “фич” (которые в течение года могут, конечно же, меняться, ведь у нас “Agile”), либо бросит бОльшую часть сил на добавление лишней девятки в наш uptime.
В то время, как что downtime, что разработанный функционал лишь косвенно влияют на корпоративные цели (продать товара побольше, потратить денег поменьше), а новые “фичи” носят больше внутренний характер и очень редко удовлетворяют “хотелки” больших клиентов.
Downtime же практически не влияет на наш business continuity: можно было бы приплести его к удовлетворенности клиентов, но они гораздо больше расстраиваются, вися на телефоне с техподдержкой, нежели когда наш money printer отрабатывает транзакции с часовой задержкой. Ну а бизнес-системы созданы таким образом, что их падение на недлительный срок никак не влияет на доход фирмы.

О чем нам стоит волноваться совсем не uptime, но RPO (recovery point objective). “Лежащая” база - нестрашно. “Лежащая” база, потерявшая транзакций на сутки - вот это это уже проблема. Но таких целей нам не ставят.

В таком контексте хочется задавать совсем другие вопросы, которые, правда, выходят за рамки тематики этого канала.

В ответ на это - https://t.me/catops/945

Посмотрите вот этот прекрасный доклад: https://www.youtube.com/watch?v=kSGiUGGu1aQ

Uptime ваших приложений и систем принадлежит вам, а не хостинг провайдеру.

ОК, по поводу Foundation - оно же Основа, Фундамент, называйте, как хотите (далее Ф.).

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

Надо понимать, что фундаментом это все называется неспроста - ошибись вы в самом начале, вы рискуете заработать целый ворох проблем и технического долга, от которого вас спасет только катарсис.
Именно поэтому Ф. занимает львиную долю человеческих ресурсов и нуждается в доскональном проектировании. Дело тут даже не правильно организации VPC и сетевого стека - нужно обеспечить грамотное управление доступом, разбивку ресурсов по аккаунтам и взаимодействие между ними, а также “песочницу” для нужд разработчиков.

Если вы проектируете Ф. в облаке Амазона, советую ознакомиться с материалом Well Architected Framework (https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf) - это поможет разобраться со структурой как будущей инфраструктуры, так и приложений.

Причем тут, спрашивается, Infra-as-Code? Когда вы создаете ресурсы через GUI консоль, Амазон под капотом создает разный набор ресурсов, о которых вы не знаете.
К примеру создавая ALB, вы создаете следующие ресурсы: сам балансировщик, listener, правила listener, target group’ы, объединяете их между собой.
Если создаются managed ресурсы (типа SQS, SNS) то с ними же создаются IAM роли, необходимые для их работы.

Делая все это через консоль, вы рискуете наплодить много мусора и не приобретаете понимания, как устроены сервисы в AWS’е и связи между ними.

Более того, допустим, вы создали Ф. через консоль. Руками прописали тэги, создали аккаунты и группы ресурсов для учета расходов и разграничения доступов. В момент когда вы захотите использовать IaC инструменты (например Cloudformation или Terraform), вам придется ссылаться на физические идентификаторы ресурсов.
И если в Terraform есть оператор data, который вытащит необходимые метаданные из существующих ресурсов, то в Cloudformation придется декларировать эти ссылки вручную, прописывая их в параметрах или вообще hardcoded (что приведет не очень неприятным последствиям, когда вы начнете дорабатывать Ф.).

Во избежание всего этого, имеет смысл задействовать IaC сразу на старте, применяя best practices в виде Pull Request’ов, Code Review и CI/CD с правилами Linter’а и каким-либо тестированием. Заодно идеально опишете, что именно вы создаете и как вы это связываете между собой.
Тут же вы ответите на много вопросов, таких как: держать ли управление конфигурацией на текущем инструменте (Salt, Ansible, Puppet, etc.) или делать инфраструктуру целиком иммутабельной и декларативной, зашивая все настройки в CFN/TF; разворачивать приложения через IaC или только ресурсы; и т.д.

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

По поводу вот этого (https://t.me/manandthemachine/380) дабы не возникало мыслей, что я очередной ИТшник, который все на свете знает и окружен некомпетентными управленцами.

У каждой коммерческой компании есть т.н. Миссия. Миссия коммерческой компании - заработать как можно больше денег (либо для самой компании, либо для акционеров).

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

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

В реальности же дела обстоят немного иначе, в дело идет бессмысленная политика, директора по производству подкупил откатами поставщик материалов, у директора по HR дополнительно стоит цель держать счетчик FTE (full time employee) как можно ниже, а у ИТ директора еще есть цель снизить косты на свой “домен”, директора по продажам так вообще “поставили”, потому что он чей-то родственник или тренер по единоборствам.
Отсюда и идут все эти байки про “некомпетентный менеджмент”, о которых все знают, но предпочитают не говорить открыто.

Конечно, так не везде. У некоторых контор целью стоит не рост прибыли, но рост компании как таковой (этим особенно страдают стартапы, финансируемые венчурными фондами), то есть нужно сделать компанию как можно “дороже”, чтобы потом ее по максимальной цене толкнуть.

Но какими бы ни были root cause’ы, в итоге мы имеем то, что имеем. “Сделайте нам круто.”