Вчерашней историей навеяло.

Когда мне нужно рисовать стрелочки и квадратики с fault tolerance in mind, я спрашиваю заказчика про RPO (recovery point objective) и RTO (recovery time objective).

Кто не в курсе - это состояние системы к моменту восстановления, например как с PITR в СУБД (RPO), и время восстановления рабочего состояния системы, с момента оповещения до момента восстановления (RTO).

Если заказчик не знает таких аббревиатур, то разговор становится чуть длиннее.

Я предлагаю заказчику представить, что система не работает Х минут. При чем не в стиле «представьте, что сервер лежит Х минут», а именно система не работает Х минут.
Если заказчиком выступает неопытный С уровень или нетехнический контингент, я преддагаю заказчику представить, что он не может (здесь используется контекст) загрузить главную страницу в течение 20 секунд (или документ, или картиночку с котиками - любой контекст подойдет). Если заказчик говорит, что ему «норм», цифра увеличивается до тех пор, пока заказчик не начинает ерзать на стуле.

В тот момент, когда заказчик, словно раджа из «Золотой антилопы», кричит «Довольно!», я записываю RTO и перехожу к похожей пытке про RPO («Сколько заказов вы готовы безвозвратно потерять при аварии?»).

Когда эти цифры получены, можно начинать соединять квадратики и кружочки стрелочками.

Проектируя вычислительные системы в Амазоне, я отталкиваюсь от следующих степеней паранойи: отказ экземпляра ЕС2, отказ AZ, отказ какого-то сервиса в регионе, отказ целого региона. Тоже самое делается с данными.

На одном проекте, задействующем S3, я настоял на настройке cross-region replication. Объем данных был довольно большой, гарантии доступа к данными должны были быть предоставлены, но мой страх потери доступа к корзине был встречен смешками о «типичной восточно-европейской пугливости».
После марта 2017 никто уже не смеялся (угадайте в каком регионе была основная корзина?).

Совсем забыл.

В Москве 18.06 пройдет AWS Dev Day.
Вы сами прекрасно знаете, про что он и для кого.

Подробности и регистрация тут: http://amp.gs/dG67

Обнимите там Стекова от меня. 😉

А вот эта история посвящается @count0ru: https://bit.ly/2WlXi9d

Я привык думать, что ИТ бардак присутствует в основном в молодых проектах и направлениях, где кучке смузихлебов без опыта доверено Принимать Решения.

Однако все не так плохо! Все гораздо хуже: http://stefanoborini.com/current-status-of-python-packaging/

Коротко о новом экзамене AWS Certified SysOps Administrator Associate:

Миша задал один интересный вопрос. Цитата (орфография и грамматика сохранена): “Мне вот интересно. Бытиё определяет сознание или наоборот? В плане почему вокруг пхпшников всё всратое обычно? Потому что они пишут на пхп или они пишут на пхп потому что всратые?”

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

Как любое уважающее себя legacy, e-commerce система, написанная на PHP, обладала большим количеством изъянов. Проблема была, конечно же, не в том, что писали на PHP, но в том, КАК писали на PHP.

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

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

Боль заключалась в том, что “новый” манер написания не проходил Code Review. Заворачивали их, потому что в конторе уже был принятый некоторый “стандарт” написания систем (как вы догадались - со всеми косяками и неэффективными конструкциями), и придерживаться стоило его. “Новичкам” не удавалось протолкнуть “кошерный” способ написания систем, потому что другим, “старичкам”, было бы сложно с ним работать - они попросту не умели и не могли (не хотели?) перестроить свое мышление.

Совсем как в эксперименте с обезьянами, бананом и холодной водой: “Здесь так принято.”

Как-то я пообещал @raxwunter начать серию блогов про AWS IAM.

Мой шкурный интерес - я устал читать одни и те же вопросы в @AWS_ru. Ну и в интернетах либо “детский” уровень, либо ссылки на курсы.

Держите первую главу глубокого погружения в IAM. Будет все, от базовых терминов до как закрывать доступ к корзине S3 по выходным и много всего прочего и интересного.

https://bit.ly/2LaDq77

Продолжаем копаться в IAM, но все по базовым вещам, таким как пользователи, группы, роли и политики: https://bit.ly/2RKbVTj

Если заметили ошибку или несоответствие, кидайте камни мне в ЛС.

Коллеги, @stekov_me продолжает организовывать для вас годные встречи-посиделки.

«Я к вам с прекрасной новостью! 4 июля, в 19:00 мы проводим очередной meetup от сообщества AWS_RU!

Темы докладов: от настоящих Архитекторов!

1) "AWS IOT. Быстрое (но не очень) решение."
Федотов Андрей, Борисенко Петр. Synergy team.

2) «Как выжимать облака» Андрей Ивахненко. Антиплагиат.ру

Ну и конечно же секретный доклад от инженеров AWS!

Трансляция будет, пицца будет, и еще несколько сюрпризов!

Адрес:
г.Москва, пр. Андропова, дом 18, корп. 2
«Райффайзенбанк»

Так как мы идем в гости в банк очень просят для СБ,
ФИО для пропусков, название компании и email.

Данные для пропусков шлите на aws_meetup@stekov.ru»

Я предпочитаю не выделываться, когда происходит какая-то авария у крупного поставщика.

Во-первых у меня нет полного контекста, во-вторых я не знаю, сделал бы я лучше.

Однако случившиеся на этой и прошлой неделе отказы вызывают у меня вселенскую тоску.

Ну вот посудите сами. Cloudflare - наш поставщик CDN для GSMG.io (и как оказалось для биржи Bittrex, с которой мы работаем). Я получил уведомление от мониторинга, что бот не может подключиться к бирже, попытался зайти на администраторский интерфейс, не могу попасть на web UI.

Столько веб сайтов были клиентами Cloudflare, что мой коллега, видя 502 практически на каждой странице, которую пытался открыть, невольно спросил: “А не у нас ли это проблемы с интернетом?”.

Починили относительно быстро (всего-то 27 минут), дерьмо случается, живем дальше.

Что меня задело, так это пробка для постмортема. А именно причина: “This CPU spike was caused by a bad software deploy that was rolled back.”

Окей. С вашим SLA 100% (почитайте их ToU, там много интересного), вы по идее израсходовали error budget на той неделе. Что там SRE Book говорит по этому поводу?

Второй момент - bad software deployment. Не bad software, не bug in the software, нет. Плохое, мать его за ногу, развертывание. Лучше б написали software related и потом оправдывались, как так получилось.

И вот знаете, не хочу ныть. Будущее (и настоящее) мне нравится, куда мы катимся и идем - мне тоже нравится, но низкое качество всего на свете уже малость… надоело.

Ну то есть - у меня рабочая машина, РАЗУМЕЕТСЯ Macbook Pro 2018 15 дюймов, топовая линейка и прочие понты. Машина наградила меня сломавшимся правым динамиком, оранжевыми пятнами на дисплее и залипающим пробелом. И судя по отзывам я не один такой.

Современный веб кишит багами. Просто откройте любимую страницу и консоль разработчика.

Про degraded performance, случающийся каждый день у неисчислимого числа сервисов, я и говорить не хочу.

И на фоне всего этого мрака, я продолжаю мрачно охреневать от Амазона.
Кто с ним работает, в курсе - каждая дока каждого сервиса постоянно кричит: “Дублируй! Резервируй! Оно упадет, отвечаю! Используй больше AZ, мамой клянусь отвалюсь!!!”

И что напрягает - не падает. Я уже и не могу вспомнить событий с момента отвала S3, когда у Амазона что-то громко падало.

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

И все мы будем хоститься на Амазоне, хотим того или нет.

Цитата из post-mortem’а Cloudflare: “Our testing processes were insufficient in this case and we are reviewing and making changes to our testing and deployment process to avoid incidents like this in the future.”

Индийские выпускники, пишущие софт для Boeing’а, это прям цветочки.

3-я глава про IAM

- Что происходит, когда контейнер стучится на S3
- Почему Condition не умеет проверять только время
- Как перестать бездумно копировать политики и начать жить
- Как ограничить доступ к роли только для определенной Lambda функции

На эти и другие вопросы я отвечаю здесь: https://bit.ly/2XotGs9

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

https://habr.com/ru/company/raiffeisenbank/blog/458420/

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

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

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

Эту идею подхватили мамкины стартапы, где инвестор заинтересован не сколько в продукте как таковом, а в том, чтобы увеличить стоимость продукта/стартапа максимально быстро (если быть точным - быстрее конкурентов, пока рыночек не порешал).

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

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

"Without requirements or design, programming is the art of adding bugs to an empty text file." (с) Louis Srygley

Очень крутое чтиво: https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/

https://aws.amazon.com/blogs/aws/amazon-eventbridge-event-driven-aws-integration-for-your-saas-applications/

А вот это очень и очень круто.

Представьте, что у вас Zendesk, и вам нужно выполнить какую-то логику в Амазоне при создании нового тикета.

Или у вас DataDog отправляет event (например оповещение, связанное с информационной безопасностью), и вам нужно срочно вывести машину из кластера в отдельную песочницу для расследования.

Я уже писал, что уровень должности (junior, medior, senior) в Нидерландах не влияет ни на что, кроме зарплаты. Когда дело касается рабочих моментов, личный бренд, приправленный этим самым уровнем, может помочь протолкнуть какую-то идею - но доказывать вчера нанятому новичку, почему надо делать именно так, все равно придется.

Однако все еще есть те, кто очень хочет иметь титул “Старший” напротив своей должности.
Когда мы открыли вакансию амазонщика к нам в контору, она изначально называлась Senior Cloud Solutions Architect. Почтовый ящик наших рекрутеров забомбили резюме специалистов из Индии и Ближнего Востока: людям очень хотелось переехать, да еще и в роли Царя Царей.

Откликались, конечно же, точно такие же Senior SRE/DevOps/Cloud/Systems инженеры и архитекторы. Эти же кадры не могли объяснить мне версионирование в S3 и отличие эфемерных хранилищ от персистентных.

Забавно то, что количество белых соискателей было на очень низком уровне. На 20 человек из Бангалора приходился 1 нидерландец.

После того, как я попросил изменить название должности на нейтральное Cloud Engineer, количество откликов из стран востока резко упало, а вот количество соискателей из ЕС и Северной Америки стало расти.

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

Но вчера небезызвестный @SinTeZoiD скинул в группу ссылку на совместный подкаст с LinkMeUp, где обсуждали такие животрепещущие темы, как Kubernetes, Docker, DevOps и SRE. Шел 2019-ый год.

За 3 часа подкаста (я успел приготовить ужин, съесть ужин, переварить ужин, помыть посуду и узнать внезапно, что Service Mesh это хипстерский Enterprise Service Bus (Миша, серьезно?)), ближе уже к концу начался настоящий замес - почему DevOps инженеров не существует.

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

Если вы в индустрии уже достаточно давно и следите за трендами, которые задают смузихлебы из креативных коворкингов, то вы знаете, что DevOps расшифровывается очень просто: Development and Operations. Такой расшифровки достаточно, чтобы все понять.

Отсюда же появляется осознание, что DevOps инженеров не может быть в природе. Если мы берем за правило, что DevOps это культура, то откуда возьмется Культура Инженер?

Если же мы берем простой акроним, то тем более не может быть Разработка и Операции инженер.

Топящие за существование DevOps инженеров любят применять следующий прием: дескать DevOps инженер занимается настройкой работы CI/CD (кто тогда Release Engineer?), работает и настраивает Kubernetes/Mesos/Nomad (кто тогда системный администратор?) и работает напрямую с разработкой (а кто этим занимался раньше?).

Не ведитесь на это. Существование DevOps инженеров обусловлено лишь тем, что вместе с культурой пришел набор практик, а за набором практик пришел инструментарий. Ищущие DevOps инженеров, на самом деле ищут специалистов, которые знают этот инструментарий.

Что мешает текущему персоналу освоить этот инструментарий - для меня загадка.

Давайте сделаем вид, что ничего не было.

Всем спокойного понедельника! Не забывайте, что здоровый сон важен. К чему приводит его недостаток, вы сами видели.

Собственно, чем был вызван шквал сообщений в канал: я сыграл в “ой, не туда”, занимаясь корректурой последнего поста @SinTeZoiD: https://news.1rj.ru/str/anykeynotes/18

А раз “спалился”, то стоит и поделиться. Впрочем, мне есть что на это сказать.

Я недостаточно стар, чтобы знать, как проходила инженерная деятельность в СССР, но я достаточно давно работаю в сфере ИТ и “повидал некоторое дерьмо”.

То, что Миша называет инженерной культурой, для меня выглядит элементарщиной.
Что значит “сборка от васяна”? Почему писать скрипты на Python, а не Bash считается неким элитаризмом?

Я могу писать свои инфраструктурные обертки на Golang. Код будет гораздо меньше, работать будет шустрее и надежнее, но скажут ли мне “спасибо” за это коллеги? Скорее всего нет, потому что они пишут на Python и Bash, и Golang не знают от слова совсем.

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

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

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

Живя в Нидерландах уже 3 года, я стал преисполнен любви к ближнему, я хочу созидать и повышать уровень русского ИТ (хотя это не дает мне ровным счетом ничего), но я забил на вторых, чего и тебе желаю. Первые сами к тебе придут, и для них надо не рефлексировать на Медиуме, но рассказывать “как надо”.

А падающего толкни.