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

2019-01-17 20:17:57 Напомнило.

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

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

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

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

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

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

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

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

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

2018-12-14 16:42:57 Отвыступался на devops conf 2018 в этом году. Прикладываю запись выступления. Если есть идеи о чем еще интересно было бы послушать - пишите в личку, буду благодарен С выбором тем у меня тяжко идет в последнее время.


Открыть/Комментировать

2018-11-01 13:56:37 Отличный разбор инцидента от 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 :)). Ведь все эти айтишные штуки и задачи - это всего лишь инструменты бизнеса. И в итоге мы это все пилим чтобы нести какую-то ценность, а не просто ради "О! Прикольная / сложная / интересная задача." Открыть/Комментировать

2018-10-30 16:26:19 Отличное дополнение пришло от Ивана Боровкова по предыдущему посту:

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

Описание кода 444 можно посмотреть тут - https://httpstatuses.com/444. Действительно использовать лучше его.

P.S. К слову я почему-то всегда использовал в блоках 444, но я думал что это просто левый код Открыть/Комментировать

2018-10-30 15:58:50 Что делать если вас начали досить или и того хуже - ддосить?

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

Обычно ддос идет из стран, которые вашему сервису не интересен. Например, если у вас интернет магазин работает в России, то навряд ли можно считать валидными пользователей из Вьетнама. Абсолютно понятно, что it depends, но если вы подходите под этот случай, то быстро отбить небольшую атаку можно и с помощью nginx. Делает это примерно так.

В начале определяется map:

map $geoip_country_code $allowed_country {
default no;
RU yes;
UA yes;
}

Мапим мы переменную, которую предоставляет geoip модуль, поэтому он должен быть подключен к nginx. В данном примере если пользователь пришел из России или Украины, то $allowed_country будет содержать значение yes. В остальных случаях - no.

Ну а дальше дело техники добавить в нужный server или location простенький if:

if ($allowed_country = no) {
return 403;
} Открыть/Комментировать

2018-10-26 19:44:38 Наверняка все сталкивались с проблемой блокировок отдельных личностей, которые постоянно лезут на вашу апишку и делают что-то гадкое. Кто-то просто забивает вам все ресурсы, кто-то регает аккаунты пачкой, а кто-то под уже существующем аккаунтом делает гадости.

Искали и смотрели как лучше избавиться от наглецов и в итоге остановились на lua + nginx. Почему? Во-первых - это просто удобно. Для lua даже специальная библиотечку уже имеется с примерами - https://github.com/openresty/lua-resty-limit-traffic. Во-вторых - никакой дополнительной логики не надо писать в приложении. А в-третьих решение простое как бревно - никаких связей приложения с nginx / fail2ban через логи. Просто видим и блочим.

Всем пятницы! Открыть/Комментировать

2018-10-23 16:10:09 Ух, интересный сегодня денек. Дебажили с какого перепугу на nvme ssd такая маленькая скорость записи рандомных блоков по 4k. Публикую что нарыли. Если у кого-то появятся какие-то идеи - пингуйте в личку, буду благодарен.

Итак, дано: SAMSUNG MZVLW512HMJP-00000, материнка https://www.supermicro.com/products/motherboard/Xeon/C236_C232/X11SSE-F.cfm, проц: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz

Тестируем через: fio —filename=/dev/nvme0n1 —name=randwrite —ioengine=libaio —iodepth=1 —rw=randwrite —bs=512b —direct=0 —size=128M —numjobs=8 —runtime=240 —group_reporting —fsync=1

Да, fsync стоит специально, чтобы не использовать дисковый кеш. Этот бенч выдает ~ 3-6 mb/s и 2k iops. Та же команда на mac book air с обычной ssd выдает 65 mb/s, 11k iops.

А судя по https://ssd.userbenchmark.com/SpeedTest/181300/NVMe-SAMSUNG-MZVLW512 - эта ссд должна выдавать от 70 до 100 mb/s на рандомные 4k.

Перерыл кучу тредов по slow performance с этим ssd на *nix системах и выделил основные направления советов:
- Проверить что разделы выравнены по 512 байт. У всех все было выравнено и все было медленно.
- Проверить что диски действительно подключены к pci express. Проверял через lshw - все ок.
- Проверить что все PCI Express подключены на CPU, а не на PCT (хз что имеется ввиду, но судя по графу lshw - PCI Express подключен к CPU).
- Проверить что процессор не ниже sky lake. У нас следующее поколение - kybe lake, так что все должно быть ок.
- Проверить в BIOS что в биосе для слотов PCI-E стоит режим M.2, а не auto и скорость X4. Не нашел таких параметров на нашей материнке, так что пропускаю.
- Очень многие писали про драйвера - типа под винду установили драйвера от ocz и сразу стало все работать - не можем проверить, поскольку у нас linux и на них нет этих драйверов.
- Так же многие писали про то, что нельзя вставлять nvme ssd в слот ниже графической карточки - типа кто-то переткнул и у них все заработало. Звучит странно, но думаю тут дело кроется в настройках биоса каким-то образом.
- И еще очень много писали про смену материнки - про supermicro ничего не писали, но много было про gigabyte & msi, типа переехали на asus и все стало волшебно.
- У nvme есть параметр write voliate memory - который похоже вообще ни на что не влияет Я его и врубал и отрубал и результаты были идентичными (кто хочет проверить - вот так можно его врубить: nvme set-feature -f 0x06 -v 0x01 /dev/nvme0, так - вырубить: nvme set-feature -f 0x06 -v 0x00 /dev/nvme0, а так посмотреть: nvme get-feature -f 0x06 -H /dev/nvme0n1 текущее значение.

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

2018-10-22 14:58:13 Всем привет, друзья! Что-то давно ничего не писал сюда. То времени нет, то настроения. Да и честно признаюсь, давно в технические проблемы не влезал - все больше проектами занимаюсь. А там основное - это команда. Ну и метрики естественно.

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

Из последнего хотел поделиться с вами прикольным зацикливанием на ansible, которое предложил один из наших студентов (да-да, мы сейчас проводим обучение):

handlers:
- name: reload nginx
service: name=nginx state=reloaded
notify: restart nginx

- name: restart nginx
service: name=nginx state=restarted
notify: reload nginx

Я вообще ставил на то, что не зациклится, но оно зациклилось. Зачем это нужно? Да фиг его знает, просто понравилось

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

Список страшных слов: java, php, linux, mysql, clickhouse, prometheus, docker, bash, dns, cdn, ansible, teamcity, CI/CD
Задачи:
- поддержка внутренних пользователей (программисты, манагеры, вот это все)
- разработка, построение и внедрение инфраструктуры как внутреннего продукта
- уверенное движение к chat-ops, no-ops
- Поддержка кучи баз данных (кол-во которых постепенно снижается), надо не бояться Кликхауса.
- Мониторинг всего и вся
- внедрение красивых CI/CD
- тотальная автоматизация, но без фанатизма
- on-call пока сутки через трое
Деньгами не обидим. Но сильно зависит от ваших талантов и умений
Работа full-remote, в Москве и Питере есть коворкинги, если не хочется сидеть дома

Откликаться можно сюда: https://airpush.com/job/devops/ Открыть/Комментировать