Продолжаем копаться в 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 года, я стал преисполнен любви к ближнему, я хочу созидать и повышать уровень русского ИТ (хотя это не дает мне ровным счетом ничего), но я забил на вторых, чего и тебе желаю. Первые сами к тебе придут, и для них надо не рефлексировать на Медиуме, но рассказывать “как надо”.

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

inb4 нет, это не реклама.

Коллеги, если кто-то ищет работу на удаленке - ScyllaDB ищет людей.

https://www.scylladb.com/career-post/senior-solution-architect/

https://www.scylladb.com/career-post/technical-support-engineer/

За всей информацией стучитесь @dyasny.

Стоило разобраться в Well-Architected Framework на более менее приемлемом уровне, как выяснилось, что существует еще и Cloud Adoption Framework.

И если WAF он про продукты на Амазоне, то CAF про, как подготовить организацию к Амазону.

Мне нечего сказать про Trunk-Based Development.
У меня 3 простых принципа: fit for purpose, KISS и YAGNI.

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

https://arstechnica.com/information-technology/2019/07/feds-former-cloud-worker-hacks-into-capital-one-and-takes-data-for-106-million-people/

Если вкратце:
1. Бывший (?) сотрудник AWS смог получить доступ к IAM роли.
2. Воспользовавшись этой ролью сотрудник получил доступ к S3.
3. Сотрудник радостно поделился об этом со всем миром, был арестован, ну и так далее.

Что говорят медиа: “взломали AWS, слили данные”

Плевать на желтушные заголовки, у меня только один вопрос: каким образом роль для сервиса WAF имела доступ в S3?

На всякий случай напомню, что я пишу цикл статей на тему IAM и как их правильно готовить: https://news.1rj.ru/str/manandthemachine/425

Достаточно иметь здравый смысл, понять принципы IAM, least privilege principle и изучить IAM Policy Conditions, чтобы не сесть в лужу.

Использование Mappings в шаблонах Cloudformation для выбора нужного AMI Id из региона - самое идиотское дело.

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

Для тех, кто, как и я, страдал похожей фигней, Амазон сделал публичный репозиторий параметров с идентификаторами машин Amazon Linux 2 (и насколько я знаю и более ранних версий). Использовать его до неприличия просто:

# Parameter section
ImageId:
  Denoscription: 'Latest Amazon Linux AMI ID'
  Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
  Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'

# Resource Section
WebServerLaunchTemplate:
  Type: AWS::EC2::LaunchTemplate
  Properties:
    LaunchTemplateData:
      InstanceType: !Ref InstanceSize
      UserData: …
      ImageId: !Ref 'ImageId'
      SecurityGroupIds:
        - !Ref 'WebServerSecurityGroup'

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

Читаю "Никаких компромиссов" за авторством Криса Восса - отставного специалиста по переговорам из ФБР.

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

Так вот в 1979 основатели проекта Роджер Фишер и Уильям Юри выпустили книгу "Путь к согласию", где описывали новую методику. В этом, не постесняюсь этого слова, труде авторы акцентировали внимание на эмоции - один из недостатков разумных существ.

Один из пунктов гласил: не зацикливайтесь на том, "что" хочет человек, но на том "почему" он этого хочет.

Даже если вы простой инженер, зона ответственности которого мала, а цена ошибки ничтожна, этот прием поможет решить большинство ваших (и не только) проблем.

Взять тот же холивар про Кубернетес. Если к вам сверху пришел запрос на изучение и внедрение оного, то задайтесь вопросом, "почему" "ТАМ" хотят кубер, облако и прочее. Решение чаще всего лежит на поверхности и не нуждается в интеграции хайповых технологий на вашем проекте.

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

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

https://learnworthy.net/highest-paid-programming-languages-in-2019/

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