Дорогие коллеги, а есть ли в стане амазонщики, желающие переехать в страну велосипедов и легальной травы?

Наша контора в скором времени откроет позицию инженера-архитектора AWS.
Из buzzwords, которые надо знать: Docker, DC/OS, TeamCity, AWS.
Как сказал мой шеф - бумажки не важны, важны навыки, но наличие амазоновских сертификатов сделает вас более привлекательным для моего работодателя. 😉

Свое резюме отправляйте мне на почту: thomas.storm@protonmail.com
Вопросы сюда - @ThomasStorm

Между делом книжку, на которую мне все было жалко денег (Database Reliability Engineering), и много других раздают за сущие копейки: https://www.humblebundle.com/books/dev-ops-oreilly?hmb_source=navbar&hmb_medium=product_tile&hmb_campaign=tile_index_3

Десктопный клиент телеги теряет отступы и тем огорчает меня. Скоро верну пост.

Опечатался, что ваш Трамп с cofveve. :))

У меня сейчас будет даже не пост БОЛИ, но скорее вопрос с коллегам из разработки.
Я писал раньше о своих приключениях с Graphite-Statsd. Так вот, наш Statsd слушает на udp. Это удобно, если по каким-то причинам коннект к машине отвалится на небольшой срок, это не будет иметь никакого эффекта на приложения, отправляющие метрики.

Однако наши ребята используют connected UDP, что означает, что приложение будет отправлять дейтаграммы через открытое соединение (если, конечно, я правильно понял, как оно работает). Что означает, что временная (даже секундная) недоступность Statsd или разрыв соединения приведет к необработанному исключению в нашем коде Scala, потому что библиотека не умеет в reconnect, а разрабы не написали обработчик, пересоздающий соединение в случае отказа.

И вот к чему это я. Вопрос к аудитории: в чем смысл использовать connected UDP, а не TCP? Поскольку получается, что мы используем UDP без преимущества UDP. Но прежде чем косплеить Лаврова (“Дебилы, бл*ть!”), хочу убедиться, что я не упорот.

Всем “вижу” и хороших выходных.

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

Прежде чем открывать портал в ад, надо сделать небольшое замечание - наш backend работает на Akka.
Для отправки метрик в Statsd используется форк akka-statsd (https://github.com/NewMotion/akka-statsd).

Внутри него настройка соединения построена по методу Connected UDP (https://doc.akka.io/docs/akka/2.5.3/scala/io-udp.html#connected-udp)
Итак, Connected UDP работает по схожей с Bind-and-Send модели. Единственная существенная разница в том, что JVM Java SecurityManager (если включен) закеширует security check после соединения один раз, что уменьшает нагрузку на ЦПУ и увеличивает производительность (при Bind-and-Send security check проходит каждый раз).
Внутри Connected UDP идет Bind к удаленному адресу и порту. Метод, создающий соединение тут (https://github.com/NewMotion/akka-statsd/blob/master/akka-statsd-core/src/main/scala/transport/udp/SingleAddressConnection.scala#L24).

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

def working(initiator: ActorRef, socket: ActorRef): Receive = {
    case Deliver(msg) =>
      log debug s"UDP delivery of stats message $msg"
      socket ! Send(ByteString(msg))
    case CommandFailed(Send(payload, _)) =>
      val msg = payload.utf8String
      log warning s"Unable to deliver message: $msg to $remoteAddress"
      sender ! DeliveryFailed(msg)
  }

Тут я перестаю косплеить ДиКаприо из “Начало” и останавливаю исследование.
Что известно на данный момент: CommandFailed это исключение, получаемое от методов Akka UDP, то есть, где-то под капотом Akka.
Внутри Akka, как сообщили коллеги, при недоступности порта даже на мельчайший срок, происходит IOException, который выдает наверх CommandFailed. Работать это начинает только после рестарта приложения, работающего с akka-statsd.

Мозгом я понимаю, зачем использовать Connected UDP. Этот способ может худо бедно гарантировать доставку трафика, не нагружая систему как с TCP, но, как выяснилось, у нас не используется JAVA SecurityManager. То есть смысла использовать именно Connected UDP нет.

Требование гарантировать доставку метрик отпало, как минимум год назад, еще до моего устройства в контору, и понадобилось пару downtime’ов, чтобы разрабы запилили UnConnected UDP и стали потихоньку обновлять приложения. Почему нельзя реализовать пересоздание connect, для меня остается тайной.

Живем дальше. Отдельное спасибо @sakalr и @Civiloid за пояснение.

Вчера на очередном собрании департамента парни из Core команды продемонстрировали новую “фичу” нашего продукта. Новое поколение зарядок способно определять пользователя в тот момент, когда он подключает свою Тезлу (и не только) к зарядной станции, автоматически запуская зарядку и тарификацию. Пользователю больше нет необходимости иметь при себе токен или карточку, чтобы запуститься. Как тебе такое, Илон Маск?

Самое интересное в таких демо сессиях, когда ты знаешь, как работает изнанка. И самое страшное, когда ты знаешь о ее проблемах.

В последние 2 недели я был занят перетаскиванием трафика на наши вебсервисы со старого балансировщика (ELB Classic) на новый (ALB), и пока я перенастраивал DNS имена), я решил поковыряться в одной проблеме, которая мучает наших разрабов уже как полгода.

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

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

И что самое ужасное - статус страница говорит, что все приложения feel fine. Перетащив часть приложений из prod я не получил ни одной весточки от разрабов с аномалиями.

И когда я смотрел, как наши корабли бороздят просторы вселенной, у меня перед глазами была лишь картинка из Doom Eternal, где среди полчищ демонов и щупалец торчали наши Lolo3.

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

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