Хмельной Девопс


Гео и язык канала: Россия, Русский
Категория: Технологии


Будничный хаос и мрак при поддержке ИТ систем.
Канал об эксплуатации ИТ систем от действующего DevOps
Для фидбека и вопросов - @vasiliyozerov


Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


Как сбросить пароль в esxi без kvm? Заметка для себя.

Первым делом стоит загрузиться с livecd (ну кто бы сомневался). Вторым шагом нам потребуется подмонтировать корневой раздел esxi и поменять пароль. И вот тут-то начинаются вопросики.

Во-первых стоит посмотреть вот эту доку - https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-474D003B-C6FB-465D-BC1B-5FD30F8E2209.html. Внутри вы найдете как esxi разбивает диск и какие разделы использует. Нас интересует раздел boot-bank-0 - на нем хранится состояние esxi сервера. Итак, смотрим нашу разметку:


# parted

... skipped ...
(parted) p
... skipped ...

Number Start End Size File system Name Flags
1 32.8kB 4194kB 4162kB fat16 boot, esp
5 4211kB 266MB 262MB fat16 msftdata
6 266MB 528MB 262MB fat16 msftdata
7 528MB 644MB 115MB
8 644MB 944MB 300MB fat16 msftdata
9 944MB 3628MB 2684MB
2 3628MB 7922MB 4294MB fat16 msftdata
3 7922MB 4001GB 3993GB

(parted)


Как видно из вывода - нас интересует раздел с номером 5 - это и есть boot-bank. Монтируем его (mount /dev/sda5 /mnt/). Далее нам требуется скопировать файлик /mnt/state.tgz в какую-нибудь директорию типа /tmp и разархивировать:

# cp /mnt/state.tgz /tmp/ && cd /tmp/ && tar zxf state.tgz && tar zxf local.tgz

После этого у нас появится директория /tmp/etc, в которой будет лежать заветный shadow файл с паролем пользователя root. Для генерации пароля используем:

# mkpasswd -m sha-512

Ну и получившийся хеш запихиваем в /tmp/etc/shadow для пользователя root. Далее делаем все в обратном порядке - собираем state.tgz, закидываем его в mnt, размонтируем раздел и перезагружаемся:

# rm local.tgz state.tgz && tar zcf local.tgz etc && tar zcf state.tgz local.tgz
# mv state.tgz /mnt/state.tgz
# umount /mnt
# reboot

Все! После перезагрузки можно входить с новым паролем 🙂


Пост про тупизм. Все когда-нибудь да тупят. Собственно на этом все. Теперь моя история про один-единственный мегабит.

Настраиваю тут давеча esxi в хецнере. Поставили, врубили, подцепили nfs для хранения виртуалочек, закинули первую виртуалку с mikrotik chr. Кто не знает - esxi за вас ничего роутить не будет, поэтому приходится создавать новый свитчик, поднимать микротик и втыкать его в две сети - внутреннюю (для которой мы свитчик пильнули) и внешнюю. На хецнере еще требуется запросить один внешний айпишник под него и сделать отдельный мак адрес, который вы вобьете в настройки виртуалки с микроток на внешнем интерфейсе.

Ну в общем поднял, настроил, добавил интерфейсы, настроил dns, dhcp, маскарадинг в firewall - все отлично. Поднял шаблонную виртуалку с ubuntu на борту. И тут началось. Запускаюapt update и 7 мб файл качается со скоростью 142 кб/сек. Ни туда ни сюда - ровно 142 Кб/сек. Вообще конечно должно было на мысли натолкнуть.

Пошел гуглить. Нашел доку от хецнера - https://docs.hetzner.com/robot/dedicated-server/virtualization/vmware-esxi/. Ну да, есть траблы с сеткой какие-то на риалтековских картах. Советуют LRO вырубать на esxi. Вырубил, ребутнул esxi - не работает. Все тот же мегабит. Блин. Пошел поменял везде адаптеры на e1000. Ребутнул микрот и убунту. Опять мегабит. Поменял адаптеры на e1000e. Ребутнул все. Опять мегабит. Да что же это такое. Пошел гуглить. Все советуют вырубать lro, какие-то треды на форумах по этому поводу - ничего адекватного.

Ну думаю придется локализовывать проблему - для начала надо поставить вторую виртуалку и погонять iperf между ними, чтобы исключить микротик. Блин! Микротик! Забыл про него совсем - пошел гуглить mikrotik slow network. И на какой-то там по счету ссылке натыкаюсь на информацию о том, что без лицензии mikrotik chr ограничивает скорость до 1 mbit/sec. Ну чтож такое-то. Пошел в микрот, зарегал лицензию и speedtest мне выдал 1 gbit/sec :joy:.

Хотя до этого где я только микроты не настраивал и где с ними только не работал. Но вот всю жизнь мне попадались уже активированные - ни разу с таким не сталкивался. Т - тупизм 🙂


Продолжая тему hasura про которую уже упомянал в предыдущем посте. По сути hasura позволяет вам получить свой бекенд с graphql на борту без разработки. Но есть небольшой нюанс -
хасура оставляет за вами реализацию аутентификации пользователей. Речь именно про аутентификацию. Авторизация в hasura есть достаточно мощная прямо из коробки. В общем про эти штуки можете подробнее почитать здесь - https://hasura.io/docs/latest/auth/authentication/index/.

Ну а я хотел в двух словах накинуть как мы реализовали процесс аутентификации у себя - вдруг кому-то пригодится. Строится все на внутреннем keycloak (https://www.keycloak.org/), который позволяет регистрировать пользователей, верифицировать их имейлы и в итоге отдавать jwt токен, который примет hasura. В целом все эти настройки достаточно хорошо описаны здесь - https://hasura.io/learn/graphql/hasura-authentication/integrations/keycloak/. Если кто доберется до этого прекрасного чтива, то заметит что внутри есть такое небольшое предупреждение:

"Warning: The users between Keycloak and Hasura do not synchronize automatically"

Типа сами занимайтесь синком пользователей из keycloak в hasura. Ведь нам же надо как-то использовать user id для join'ов внутри базы. А пользователи-то в keycloak лежат. Ну вот
и требуется их как-то синхронизировать. Быстрый гуглеж ничего толкового не выдал. Ну точнее выдал, но скорее это были несколько трупиков, похороненных пару тройку лет назад. Приш
лось изобретать велосипед и писать собственный синхронизатор. Результаты моего быдло кодинга можно найти здесь - https://github.com/vozerov/keycloak2hasura.

А пока в кратце опишу как все было реализовано. Схема простая как две копейки. В keycloak внедряется rabbitmq plugin (https://github.com/aznamier/keycloak-event-listener-rabbitmq), который слушает ивенты от keycloak'а и публикует их в rabbitmq. Мой велосипед слушает эти ивенты, парсит их и с помощью graphql запросов создает / удаляет пользователей в hasura. В итоге все работает и все довольны. Вообще в readme накинул поподробнее, так что можете посмотреть.

Из интересного - в main.go можете найти модуль rabbitmq для golang, который создает отказоустойчивого консьюмера. Если у вас отвалится реббит, то он будет пытаться переподключить
ся до последнего. Очень актуально при использовании всяких балансировщиков - иначе ваше приложение встанет, как только закроется подключение к реббиту. Что видимо не очень хорошо
скажется на работоспособности вашего решения 🙂

P.S. Код писался для себя на коленке, так что какашками закидывать можно, но лучше сразу pull request'ами.


Статистика первого поста после возвращения достаточна интересна - отписалось порядка 400 человек и кто-то влепил целых 5 какашек. Я тоже по вам скучал 🙂

Ну а сейчас немного про graphql. Кто не слышал - почитать детально можно здесь - https://graphql.org/. Но в двух словах - это язык запросов для API. Приведу простой пример. Предс
тавьте что вы разрабатываете онлайн сервис кинопоиск (или любой другой). Он хранит информацию о фильмах и актерах, которые в них играют. Для получения этой информации вам доступн
о два API метода - get /movies и get /actors. По первому вы получаете список фильмов, а по втором список актеров. Если вы захотите на одной странице вывести фильмы и фамилии акте
ров, участвующих в них вам придется сделать несколько запросов к разным endpoints. Что не очень-то удобно, да и к тому же увеличивает время ответа. А вот graphql позволяет исполь
зовать один endpoint и получить ровно те данные, которые нужны. Для задачи выше можно использовать такой graphql запрос:


{
movies {
name
actors {
familyName
}
}
}


И все! В ответ мы получим список фильмов с фамилией актеров, которые там играют. В общем тема крутая - советую посерчить и поиграться. Опять же на сайте graphql.org есть много примеров - https://graphql.org/learn/queries/.

К чему я это все. А к тому, что на одном проекте нам потребовалось быстренько сообразить backend на graphql. И пришлось окунуться в мир потрясающих технологий. Тут вам и dgraph, и hasura, и edgedb и еще куча всего. Суть проста (edgedb & hasura) - вы запускаете прослойку, которая в качестве backend'а использует обычную базу - например, postgres. И по факту эта прослойка реализует ваш backend. Вы кидаете в нее graphql запросы, а она парсит их и выполняет в базе. Ну захотели вы запросить тот же список фильмов с актерами - edgedb принял запрос, распарсил его, полез в postgres, вытащил данные и отправил их вам. Безумно просто и функционально. Теперь прототипирование становится легче на порядок - бекенд-то у вас теперь всегда под рукой!

P.S. Мы выбрали для тестов hasura и уже успели с ней поиграться и даже привязать аутентификацию к keycloak через jwt токены - возможно попозже напишу как и что там работает. На связи.


Как же давно меня здесь не было 🙂 Но настало время вернуться. Изначально я хотел написать что-нибудь 26 апреля 2022 года, чтобы было красивое возвращение, но я благополучно просрал эту дату, поэтому вот он я 6 сентября 2022 года 😂

Из последних новостей делюсь инфой (сотка) что поднять чистый kuber кластер на российсиких технологиях (redos) вполне реально. Забавное конечно было предприятие и оно даже не заняло сильно много времени. Собралось все практически по шагам kubernetes the hard way, за исключением буквально пары моментов. Один из которых - требование использоваеть чистый openssl без всяких там pki упростителей типа cfssl. И тут я еще раз поразился той красоте, с которой работают SSL сертификаты. Просто потрясно, когда вы можете сделать свой корневой сертификат, подписать им серверные и клиентские серты и после этого ваш клиент будет абсолютно безопасно проходить аутентификацию на сервере - ну просто красота же!

На всякий случай дублирую команды для генерации CA и клиентского сертификата, чтобы не забыть и не лезть опять в гуглище:

CA Authority:

# CA Authority key & crt
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -subj "/CN=kub-cpl" -days 10000 -out ca.crt


Admin certificate:


# admin cert
openssl genrsa -out admin.key 2048
openssl req -new -key admin.key -subj "/CN=admin/O=system:masters" -out admin.csr
openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out admin.crt -days 1000


ApiServer cert:

# apiserver cert
openssl genrsa -out server.key 2048

cat > server.conf


Время завершения в днях


Кол-во задач


Как я работаю с задачами.

В последнее время часто приходиться заниматься интеграциями. Тут надо zoom api привязать к бекенду на гошечке, чтобы генерировать уникальные ссылки на вход. А тут инфу по сделке в битрикс закидывать. А вот здесь еще оплату через я.кассу принимать. Ну и давайте еще рассрочку от тинкова и альфы подключим, чего уж там.

На самом деле интеграции только полбеды. Я квантую свое время как могу. Вот выдался часик ген дира - подпиши всякие юридически значимые штучки. А вот часик фин дира на подходе - распланируй бюджет, занеси все для учета, выплати зп, да и про себя не забудь. Или часик продажника - сходи на встречу, поболтай, расскажи как вы работаете и закрой на аудит. Часик CTO - поработай с подрядчиками и проверь что ивенты на просмотр видео успешно приходят и апдейтят сделку в битре (сюда же QA вписываем часик). Часик программирования от него тоже никуда не деться - api'шки сами себя не привяжут. А еще было не плохо вебинарчик зачитать с довольной мордой 🙂

К чему я это все? Да просто с этими интеграциями наткнулся на api wunderlist'а, который прекрасно отдает время создания и закрытия задачи. Заимпортил все в постгрю (часик программиста на питоне) и построил пару графиков.

На первом - количество задач. Вообще оно не так сильно плавает, не считая отпуска. Но есть реперные точки - особенно Airpush в октябре 2017 года. И конечно запуск Rebrain в начале 2019. Хотя тут я больше склонен считать, что мой уровень декомпозиции задач вышел на новый уровень. Особенно если сравнить эти же числа со вторым графиком - среднее время завершения задач в днях. Видно же, что стал быстрее вхерачивать.

Вообще я давно искал метод как мне работать с задачами. Всякие жиры, трелло и асаны идут лесом, поскольку до них очень тяжело дотянуться. А задач прилетает достаточно много - порядка 20 штук в день. Это могут быть как и мелкие вещи, типа залить сайти, добавить страничку оплаты, зарендерить вчерашний видос, так и более муторные - типа описать процесс проверки ДЗшек или проанализировать схера ли мы тут в кассовый разрыв попадаем.

И пришел я к простому выводу - в параллель я могу делать порядка 3-4 задач. При этом я точно не должен отвлекаться ни на что другое. Поэтому когда мне прилетает сообщение в ТГ / почту и так далее - я просто за 5 секунд не раздумывая над ним закидываю его в wunderlist. И продолжаю делать то что делал. При этом текущие задачи из головы я не выгружаю пока не дойду до промежуточной точки. Ну или не усну. Как только задача доведена до чекпоинта - сижу и разгребаю wunderlist - кому-то отвечаю, что-то смотрю, что-то заливаю. И так до следующей тяжелой и долгой задачи.


Рассказывал я тут на вебинаре про Nginx tips & tricks. Про nginx check module, mirroring и lua.

Всю жизни думал, что mirroring модуль не аффектит продакшен запросы, но я ошибался. Действительно, есть некоторый набор параметров при котором nginx может дожидаться ответа от тестового окружения и при этом откладывать ответ боевому клиенту. Больше информации здесь от Nginx Lead Developer: https://forum.nginx.org/read.php?2,281042,281042#msg-281042.

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


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

С одной стороны ничего сложного - вычитаем из поля responded_timestamp значение поля created_at и получаем время ответа. Или среднее или персентили - все что душе угодно. Но блин, ведь заявка, созданная вечером, в нерабочее время будет обработана только с утра. Это как минимум часов 8. А нам надо как-то учитывать только рабочее время - исключать праздники, выходные и время с 19 до 10

Забыл упомянуть, что все данные хранились в эластике - просто грузили все тикеты и информацию о них в json'ке. А для визуализации у нас была кибана. Собственно выбор был очевиден - нужно использовать scripted fields и писать скрипт на языке painless. Быстрый гуглинг результатов не дал - никаких исходников или скриптов примерно решающих ту же задачу не нашлось.

Пришлось отдавать на аутсорс и писать собственное решение. Именно им я и хочу поделиться с вами, уважаемые коллеги. Если вдруг кто-то использует kiban'у как BI инструмент и хочет рассчитывать разницу между двумя датами с учетом рабочего времени - welcome! Скрипт вы можете найти здесь: https://gist.github.com/vozerov/c3578e727e511cd99fd7e9af3e348e14

Если у кого-то если желание его доработать или добавить функционала - пишите, опубликую ваши апдейты 🙂

P.S. В итоге все равно ушли на редаш с постгресом - не смогли добить некоторые метрики в эластике без join'ов.


Вы наверняка забыли про мой опрос от 1 июня 2018 года, но Васян все помнит! Давайте немного освежу вам память:

Было бы прикольно записать какие-нибудь простые видосики на разные темы: Основы работы сетей, Как работает DNS, Как работает HTTP/SMTP/etc. Что скажете? Если вдруг вам идея понравилась, то заходите и предлагайте о чем рассказать - https://goo.gl/forms/w4J811agiSrNtvii2, я соберу все ответы и попробую успеть записать первое видео на следующей неделе.

Со следующей неделей я конечно погорячился, но мы сели, подумали и решили реализовать более масштабное мероприятие. Идея родилась сама собой. Как вы наверняка знаете, в последние полгода мы активно влезли в обучение молодых ИТ-шников. И мы явно видим запрос на крутые профильные мероприятия. К сожалению, лично посетить офлайн митапы или конференции могут не все. Либо из-за невозможности приехать, либо из-за стоимости билета.

Поэтому, мы с гордостью представляем первую онлайн конференцию по инфраструктуре и DevOps - http://bit.ly/fevlakeconf! Формат мероприятия абсолютно новый, отчасти можно сказать даже экспериментальный.

Все выступления будут проходить в режиме реального времени. Вы сможете задать интересующие вас вопросы, на которые спикер ответит после выступления. Так же мы пригласим вас в закрытый чат, где вы сможете пообщаться и получить ответы на любые вопросы. Коммьюнити - это самое крутое что у нас есть, ведь так? 🙂

Что касается меня, то я планирую рассказать про troubleshooting инфраструктурных проблем на примере реального проекта. А послушать точно пойду Бориса Горячева про принятие хаоса в разработке на примере Медузы (у всех же хаос есть, да?).

До встречи! Увидимся на конференции!




Все. Не могу больше. За последние три дня я получил 5 вопросов о том что такое percentile (он же персентиль или процентиль). А я всего-лишь имел неосторожность указать в ТЗ на разработку системы аналитики для нашего курса, что помимо среднего времени прохождения задания нам еще нужны персентили. Это же персентиль, Карл! Они же практически везде в IT вылезают.

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

Вместо предисловия рекомендую купить и прочитать отличную книгу про статистику: https://www.mann-ivanov-ferber.ru/books/golaya-statistika/. Книга написана простым языком и повествует о том как вообще смотреть на всякие статистические показатели.

Возвращаемся к персентилям. Давайте представим себе ситуацию, что на нашем небольшом, обитаемом острове живет 10 человек. И у первого зарплата 10 тысяч, у второго 11 тысяч, у третьего 12 и так далее. У последнего 19 тысяч.

Средняя зарплата 14 500 рублей (не верьте на слово - проверьте!). А теперь давайте одному аборигену зарплату поднимем до 300 тысяч. Среднее тут же возрастает до целых 42600. Но блин, ведь у большинства зарплата в несколько раз меньше среднего! Вот тут на сцену и выходят персентили - они позволяют легко и непринужденно отсекать различные пики и всплески.

50-ый персентиль (он же медиана) в нашей гипотетической ситуации до повышения зарплаты будет так же равен 14500. Он показывает, что 50% людей получают 14500 или меньше, а другие 50% - 14500 или больше. Если взять 70-ый персентиль, то он уже будет равен 16300, что означает что 70% людей получают 16300 или меньше. А остальные 30% 16300 или больше.

Все просто? Круто! Теперь давайте повысим зарплату нашему поселенцу до 300к. Как мы помним среднее у нас поднялось до 42600. А вот 50-ый и 70-ый персентили не изменились - потому что у нас 70% как получали 16300 так и получают. Изменения коснулись только оставшихся 30%.

Где это применяется? Да везде. Когда вам говорят среднее значение зарплаты и не говорят медианы - вас набманывают. Точнее говорят приятную часть и опускают ту, которую вам лучше не знать. Но без медианы абсолютно непонятно как получилось среднее - может 100 человек получают 100 рублей, а один известный нефтяной управленец миллиард, вот вам и нормальная средняя зарплата.

Если возвращаться к IT, то самое частое применение - это полоса трафика к вашим серверам. Очень часто счет вам выставляют на основании 95-ого персентиля по используемой полосе. Что следует читать как: 95% времени вы использовали 3 mbit/s (или сколько там у вас). А остальное время может и были какие-то пики, но мы их не учитываем.

Или еще хороший пример - время ответа веб сервера. Если 99-ый персентиль равен 200ms - это означает, что 99 процентов ваших клиентов получают ответ от сервера за 200 ms или быстрее. И если вдруг какой-то тип по 2G будет получать ответ в течении 10 минут - ваша статистика не сильно испортится и вам не придется гадать почему вдруг среднее время ответа выросло до 300 ms.

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


Как чистить место на диске?

Вроде и вопрос банальный и проблеме сто лет в обед, но в последнее время он возникает так часто, что я решил написать несколько строк по этому поводу. С технической стороной вопроса все вроде бы понятно. Мониторинг настроили, алерты приходят, rm -rf отрабатывает. Но как быть с организационной частью?

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

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

Простой пример. У вас есть статистика по продажам вашего продукта. И вот вы поставили задачу хранить столько, сколько влезет на диск. Отлично! В какой-то момент на этой же базе разрослась тестовая таблица. Действуя согласно плану по хранению статистики продаж вы взяли и дропнули все данные за последний год и оставили там последние пару дней. Под условие подходит? Да. Мы нарушили инструкцию? Нет. Все правильно сделали? Да. А бизнес только что продолбал все историю продаж благодаря условию "храним сколько влезет".

Если бы у вас была политика хранения и очистки статистики продаж, то вы бы не смогли взять и удалить эти данные. Вы бы пошли искать что еще занимает место на диске, попытались бы очистить что-то другое. И в конце пришли бы к бизнесу с вопросом - нам нужны деньги на диск. И смогли бы это обосновать за 10 секунд. Примерно так: "Согласно политике, эти данные надо хранить 5 лет. Диск у нас на 1Тб - он закончился. Так что либо докупаем диск, либо меняем политику хранения".

Поэтому ответ на вопрос "Сколько и какие данные хранить?" безумно важен. Вы должны четко понимать кто и как использует какие данные и в зависимости от этого выработать политику очистки, агрегации и архивации этих данных. Совместно с продуктом, конечно.

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


Репост из: запуск завтра
Amazon две недели разбирался и ответил, что простит половину счета за трафик, который мы случайно нагенерили в конце года. Cloudflare простил весь счет за трафик в указанном периоде. УРА!

Не стесняйтесь просить помощи. Люди и компании вполне могут пойти вам навстречу.


Напомнило.

Была у нас (да и сейчас есть) группа студентов, которых мы обучаем девопс практикам. И было у нас одно задание на terraform. Выдали мы значит ребятам токен от Амазона, чтобы потренировались виртуалки создавать, security настраивать ну и тому подобное.

Все шло как по маслу. Виртуалки создавались, знания получались, солнышко светило. Но тут пришла тучка. Точнее не тучка даже. В общем закоммитили конфиг терраформа в гит вместе с токеном от амазона. Естественно в открытом виде. Боты это дело быстро просекли и насоздавали по 20-30 самых мощных виртуалок в каждом регионе. Майнили, сцуки.

Первыми забивили тревогу нащи ребята, которые в тот момент (3 ночи примерно МСК) игрались с терраформом. Начали пинговать, звонить и гасить левые виртуалки. Я в этот момент видел свой любимый десятый сон. В общем с утра я проснулся. Охренел. Токен заблочил. Тачки снес. Посмотрел cost explorer - 36$. Ну и отлично, - подумал я. Чуть выше обычного.

Прошел день. И обновилась статистика использования. 4k$. В тот момент я немного (нет) напрягся. Расстроился. Испугался. Не помню, но было не круто.

Написал в саппорт с описанием произошедшего. Меня заставили сменить все токены, пароли, подрубить 2fa и сделать прочию любимые всеми безопасниками вещи. В конце передали мой запрос в billing team. Три напряженных дня и мне выдали промо код на 3970$.

Вывод будет тот же самый - не бойтесь писать и спрашивать. Главное не бегите и не блокируйте карты - попадете в какие-нибудь черные списки.


Обрабатываем 10 000 RPS входящих сообщений на инфраструктуре за 60$ / month. Это самый желтушный заголовок, который я когда либо писал.
На самом деле в последнее время получаю много вопросов по поводу того что выбрать - kafka или rabbitmq для организации очереди сообщений. Чтобы снизить поток входящих, набросал статейку с очень простым субъективным мнением о том что и когда стоит использовать. В конце вы найдете полезные ссылки для более глубокого погружения.

Ах, да, чуть не забыл - вот ссылка на статью - https://medium.com/@vozerov/kafka-vs-rabbitmq-38e221cf511b


Очень крутую штуку ребята сделали конечно - https://github.com/spiral/roadrunner. Вдохнули в пхп проекты новую жизнь, так сказать. Больше деталей и описания здесь: https://habr.com/company/badoo/blog/434272/


Отвыступался на devops conf 2018 в этом году. Прикладываю запись выступления. Если есть идеи о чем еще интересно было бы послушать - пишите в личку, буду благодарен 🙂 С выбором тем у меня тяжко идет в последнее время.
https://www.youtube.com/watch?v=sZdEDHaNhY8
Revenue Based Monitoring / Василий Озеров (fevlake)
DevOpsConf Russia 2018 Зал «Зал 2. На краю Вселенной», 2 октября, 11:00 Тезисы и презентация: http://devopsconf.io/moscow/2018/abstracts/3444 Все IT-компании...


Отличный разбор инцидента от github'а: https://blog.github.com/2018-10-30-oct21-post-incident-analysis/. Люблю читать детективы 🙂

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

"Adjust the configuration of Orchestrator to prevent the promotion of database primaries across regional boundaries. Orchestrator’s actions behaved as configured, despite our application tier being unable to support this topology change. Leader-election within a region is generally safe, but the sudden introduction of cross-country latency was a major contributing factor during this incident. This was emergent behavior of the system given that we hadn’t previously seen an internal network partition of this magnitude."

Но лучше всего описать мою мысль смогли комментарии под переводом статьи на хабре:

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

И вот в последнее время я все больше подхожу к мысли, что обычные интуитивные методы решения технических задач не всегда работают. Всегда хочется поставить задачу сделать отказоустойчивую систему. А вам точно это нужно? Может у вас день простоя стоит 100$ и вам нет смысла тратить 100k$ на решение и внедрение в этом случае? Или нужно ли вам резервирование active-active между ДЦ, если ваш текущий датацентр лежал 2 часа за прошлый год? Или нужна ли вам реплика базы физическая, если вы сможете восстановиться из бекапа за 10 минут?

Я конечно понимаю, что я сейчас накинул и мне прилетит, но все же я считаю, что нафиг не надо внедрять все подряд что в тренде. Надо всегда оценивать что вам принесет или не принесет то или иное решение. Старайтесь смотреть на ситуацию шире, подводить к какому-то общему знаменателю (да, это я про свой доклад revenue based monitoring :)). Ведь все эти айтишные штуки и задачи - это всего лишь инструменты бизнеса. И в итоге мы это все пилим чтобы нести какую-то ценность, а не просто ради "О! Прикольная / сложная / интересная задача."

Показано 20 последних публикаций.