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

Во-первых, далеко не в каждом бизнесе встречается толерантность к косякам со стороны ИТ. Одна из причин “медленного” производства ИТ продуктов в таких компаниях, как банки, госсектор, добыча ресурсов, фин сектор, трейдинг, оборонка, космическая и авиационная отрасль и т.д., в том, что обновления софта проходят (либо должны проходить) многодневную скрупулезную проверку качества поставляемого продукта. Иными словами, там полный ITIL/ITSM с change management’ом, когда под малейший патч подписывается огромное количество ЛПР.
Во-вторых, похожим образом ведут себя разработчики криптовалют из топ 5, в частности разрабы Bitcoin. На кону не только их репутация, как спецов, но и репутация самого битка, которая и так страдает от нападок экономистов из общего сектора классических фин. инструментов.

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

Те, кто меня давно читает, помнят мою историю, когда я облажался с настройкой DHCP серверов, задав неправильные октеты CIDR в Puppet. Тогда это проверилось serverspec’ом и code review, но косяк все равно прошел и обрушил половину серверов в продакшене. Я отделался лишь тем, что с позорным лицом (не хватало еще тетки с колокольчиком из Игры Престолов) ходил с печеньями от комнаты к комнате, раздавая их и рассказывая, что я наделал и почему так больше не буду.

Впрочем не я первый и не я последний, кто ломал прод в этой конторе. В employee handbook для сотрудников Coolblue Tech фигурировала строчка: Fail more often.
Agile Coach, проводивший для меня и других новичков тренинг по Scrum, говорил: “Если вы боитесь что-то трогать в текущей инфраструктуре, например, обновлять ОС на серверах СУБД - делайте это чаще.”

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

Уставы ICAO (Международная Организация Гражданской Авиации) написаны кровью. Каждый разбившийся самолет, каждый сбитый малайзийский боинг служат поводом для пересмотра и обновления правил, которым следуют (и должны следовать) все авиаперевозчики.

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

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

https://aws.amazon.com/blogs/aws/new-predictive-scaling-for-ec2-powered-by-machine-learning/

Machine learning здорового человека. Больше не придется руками возиться с scheduled scaling policies.

Попался на глаза проект LocalStack, фреймворк, эмулирующий API Амазона на локальной машине.
Идея проекта - облегчить жизнь разработчикам, разрабатывающим и тестирующим свои приложения, тесно взаимодействющие с AWS.

Проект активно развивается и в будущем планирует поддерживать не только больше сервисов Амазона, но и сервисы других облачных провайдеров.
Из того, что ну очень понравилось - можно не только эмулировать соединение к ресурсам, но и создавать ресурсы и объекты внутри них. То есть, можно создать S3 bucket локально и загрузить туда файлики. Тоже самое касается очередей SQS и таблиц DynamoDB.

На данный момент к установке доступно Base Edition, поддерживающее определенный набор сервисов, а в будущем разрабы обещают махровый enterprise-edition за деньги, но с официальной поддержкой со всеми вытекающими.

Подробнее про проект можно почитать тут (https://localstack.cloud/), а репозиторий проекта доступен здесь - https://github.com/localstack/localstack

https://aws.amazon.com/about-aws/whats-new/2018/11/s3-batch-operations/

2018-ый год подходил к концу, Амазон наконец-то внедрил batch операции в S3.

Минутка оффтопа: в докер завезли третьих героев https://hub.docker.com/r/bmst/h3demo/

(Поправка: завезли его туда уже давно)

Пятничное от @theaftertimes

Амазон в этом году в ударе, но есть два новшества, вызывающие у меня сомнения.

Ground Station, сервис по сборке телеметрии со спутников на орбите, может выглядеть «прикольным» для маленьких студенческих проектов, но я слабо представляю, как NASA или, прости Господи, Роскосмос и ESA будут пропускать данные через «агентов госдепа».

AWS Outposts выглядит более «приземленным». Если вкратце - вы заказываете у Амазона оборудование, устанавливаете его в своем ЦОД и управляете им через консоль и API. Это выглядит интересно для организаций, которые по ряду требований должны хостить что-либо у себя «дома», однако это убивает главное преимущество Амазона, когда о твоей инфраструктуре печется кто-то другой. Другое дело, что этот сервис должен конкурировать со схожим сервисом от Azure и предназначен скорее для кровавых энтерпрайзов, которые держат все внутри.

Но я не могу представить себе кровавый энтерпрайз, который ну очень сильно хочет в Амазон, НО - у себя дома. Тем более при условии, что Амазон берет на себя управление этими машинами (установка обновление и обслуживание), что уже говорит о том, что у «левых дядек» есть доступ к инфраструктуре, а значит и к данным.

Помимо этого Outposts пока что поддерживают только запуск инстансов ЕС2. В будущем планируется внедрить поддержку RDS, ECS, EKS, SageMaker и EMR. Как по мне, локальные S3 и DynamoDB выглядели б гораздо интереснее.

О бывшем работодателе либо хорошо, либо NDA.

Все почитали статью “We need to kill DevOps”?

Если нет, то вот вам оригинал (http://ageofpeers.com/2017/09/14/we-need-to-kill-devops/) и перевод (https://realitsm.ru/2017/11/my-dolzhny-ubit-devops/)
Я читаю оригинал, так что за качество перевода не ручаюсь.

Во-первых, желтушные заголовки это то, что я жду от криптожурналистов из CNBC или авторов контента на всяких BuzzFeed и прочих HuffingtonPost, но никак не от коллег по цеху.
Во-вторых, считать, что DevOps виноват в том, что люди “неправильно” его внедрили, запилив DevOps инженеров и DevOps команды, то же самое, что обвинять Sinterklaas’а в том, что белые дети в школах дразнят черных детей Zwarte Piet’ами. Проблема расизма в школе это проблема расизма, а не псевдоистории (кстати, офигенной истории!), превратившейся в детский праздник. Проблема все еще живого Silo в DevOps это проблема внедрения культуры, а не самой культуры.

Предложение заменить все должности в разработчиков (т.е. разработчик приложений, разработчик БД, инфраструктурный разработчик) тоже не решение - можно назвать утку карасем, но она не перестанет крякать.

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

Есть два простейших способа сделать у себя DevOps без выноса мозга и бессмысленных ребрендингов.

1. Берем условных Ops, они создают foundation и предоставляют свои сервисы именно как СЕРВИСЫ. Если разраб хочет виртуалочку - два клика на условном портале. Если разраб хочет мониторинг - два клика на условном портале. Хочет развернуть приложение - два клика (ну ладно, три). Все запросы от разработчиков либо идут через самообслуживание, либо решаются сами благодаря автоматизации.
2. Разбиваем Ops и Dev на условные продуктовые команды, внутри которых уже есть нужное количество Ops, Dev, QA и кого бы вы туда не захотели поставить. Заодно решаем проблему “свободы”, когда команда А хочет писать на .NET, команда B хочет запускать свои приложения в k8s, а команда C хочет юзать Java и Oracle.

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

Порадуйте фаната DOOM, сделайте мне 666. ^^

Кто будет в Москве? Срочно на дебют!

Давненько я не писал о чем-то постороннем.

В Нидерландах есть несколько резидентских статусов, в моем случае это KM - kennismigrant (он же knowledge immigrant, он же highly-skilled immigrant) - категория ВКС, которые переезжают в НЛ по приглашению на работу (либо сами получают такой статус), якобы принося в страну сакральное ЗНАНИЕ, которого стране якобы не хватает.

У статуса КМ есть небольшой недостаток (надо работать и платить налоги, иначе депортация через 3 месяца) и большое преимущество - 30% рулинг, налоговая скидка на 8 (пока что) лет, освобождающая от НДФЛ 30% вашего дохода и полностью освобождающая от налога на инвестиции.
Помимо этого обладатели налоговой скидки могут без экзаменов обменять свои иностранные права на местные, причем не только обладатель скидки, но и все члены его семьи, зарегистрированные с ним по одному адресу. Так что мы с женой, пока “прет”, взяли в охапку все необходимые доки, отправили их в местный муниципалитет и получили новые права, а старые сдали в местный минтранс.

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

Так вот, чтобы вернуть права особо ничего не нужно. Как только RDW (нидерландский минтранс) подтвердил, что права хранятся в русском консульстве, я обратился туда. Стоит отметить, что с момента переезда я никак не коммуницировал с русскими authority (Бог миловал).

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

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

Впрочем, “как дома” мы себя почувствовали, как только добрались до ворот консульства. Меня предупреждали, что ждет нас там только совок и хамящие тетки, но грубый прокуренный голос в домофоне (“Подойдите ближе к микрофону, я вас не слышу!”), женщина, небрежно бросающая residence permit в лоток, впервые встреченные в Нидерландах ТОЛСТЫЕ (ну вот реально ТОЛСТЫЕ) русские люди вызвали у меня не чувство отторжения, про которое я привык читать на иммигрантских форумах.

По непонятным мне причинам я испытывал лютый восторг и улыбался как дебил (даже когда объяснял охраннику, похожему на рекетира из девяностых, что он не может меня найти в списке по записи, потому что я не записывался).
Еще больший восторг я испытал, когда жену позвали к окошку на подачу документов на новый загран за целых 40 минут до времени ее записи (мы прибыли за час, чтобы забрать права).
Мы забыли купить марку для конверта (хоть это и фигурировало в списке документов), заполненная форма выглядела странно из-за сместившейся нижней рамки в разделе “чем вы занимались последние 10 лет”, но все эти недостатки, за которые меня выгоняли из офисов ФМС в России, здесь игнорировались. Девочка в окошке была настолько доброжелательна, что у меня появилось непреодолимое желание постоянно ездить в консульство, чтобы просто проникнуться атмосферой “маленькой” России в чужом мне государстве.

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

Кто еще не успел записаться, но все еще хочет.

Зарегистрировался на митап по Куберу в Амстердаме.

Цитирую название: Update from KubeCon Seattle & Management DC/OS & k8s & 70+ ways to deploy k8s.
Более 70 способов развернуть Куберенетес. Семидесяти, Карл!

Что мне нравится в современной open source тусовке - каждый имеет возможность придумать что-то свое. Что-то, что решает проблемы предшественника или расширяет его возможности.

Что не нравится - 70 разных (наверное) способов сделать одно и то же.

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

Год подходит к концу, и в ближайшие пару недель я не буду выходить на связь. После ожидайте еще одну серию длиннопостов, про жизнь в НЛ.

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

Во-первых про сам канал. Очень маленький круг людей знает, что я забросил канал в начале года из-за личных обстоятельств. Эти обстоятельства все еще со мной, и я не знаю сколько времени мне предстоит, чтобы дойти до стадии принятия.
Тем не менее спасибо моим друзьям и близким, что несут эту ношу. Я знаю, что других ударило гораздо сильнее, чем меня.
Отдельное спасибо тусовочке Дежурного DevOps’а, группе DevOps Moscow и в частности @servers , за то что мотивировал меня писать и дальше. Я начал этот год с 20 подписчиками, и для меня это взрывной рост.

Во-вторых, спасибо @count0ru , @SinTeZoiD , @mo1seev за веселые посиделки в Москве и за то, что приоткрыли мне дверь в мир увлекательных дивапс мемасиков (и за то, что методично и профессионально поджигают мою архитекторскую задницу).

В-третьих, спасибо @stekov_me за титаническую работу над сообществом aws_ru. Жду дальнейших продвижений в развитии школы и сообщества. Ты знаешь, что я всегда готов помочь.

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

В-пятых, спасибо моим ученикам за терпение. Я знаю, что порой у меня скверный характер.

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

Всех с наступающим Новым Годом!