В DevopsTrain 👾

Ранее я делал пост о том, почему важно прокачивать скилл программирования для целей devops.

Теперь хотелось бы немного углубиться в тему, чтобы показать почему имеет смысл освоить Golang хотя бы на базовом уровне.

В различных материалах вы можете найти отсылки на Python в качестве языка для автоматизации задач администирования. В целом это так, но у Go есть ряд преимуществ, именно поэтому большинство современных devops инструментов написаны на нем.

✅ Удобство развертывания

Вам не нужно зависеть от наличия python интерпретатора и зависимых библиотек на целевой системе, чтобы ваша программа заработала. Все что вам нужно - это собрать под целевую архитектуру и ОС исполняемый файл через go build.

✅ Статическая типизация

Множество ошибок может быть поймано еще на этапе сборки, что сильно повышает надежность программы. В python тоже можно задавать типы, но можно и не задавать =)

✅ Эффективность

Go тупо быстрее чем интерпретируемые языки вроде Python или Ruby. Это факт. И памяти он ест меньше. Благодаря встроенной поддержки с первого релиза конкурентности, писать асинхронный код и запускать задачи в несколько потоков довольно просто и быстро.

✅ Стандартная библиотека

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

В целом экосистема и количество носителей языка Go хоть и уступает по размерам Python, но все же очень масштабная. Не даром эти известные проекты написаны на Go:
Kubernetes, terraform (и большинство продуктов HashiCorp), docker, minio, hugo, restic, grafana, prometheus и многие другие.

С чего начать изучение DevOps? 🤔

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

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

К фундаментальным вещам я отношу:

1️⃣ Основы операционных систем, в частности Linux, как безальтернативный вариант для devops. Сюда же относятся и файловые системы, и наборы популярных утилит для управления системой и траблшутинга. Работа в терминале - обязательно.

2️⃣ Компьютерные сети. В своей реализации они платформонезависимые (фундаментально), но уметь приложить к нужной ОС или оборудованию может быть полезно.

3️⃣ Виртуализация и контейнеризация. Нужно уметь различать их и знать области применения.

4️⃣ Основы автоматизации и программирование. Умение написать программу или скрипт на одном языке сильно поможет вам в освоении другого. Ведь главное - это сам принцип.

👉 Это, пожалуй, база, с которой вы сможете двигаться дальше и изучать уже более узкие и более оплачиваемые инструменты вроде этих ваших кубернетесов, ci/cd и терраформов.

На платформе Devopstrain из базовых есть курсы Linux & Networks, а также Docker 🤌.

А всегда ли нужен CI/CD?

Сегодня порассуждаем на эту тему.

Принципы devops практик рекомендуют выстраивать полные цепочки поставок: от коммита до деплоя. Но всегда ли нужно следовать этим принципам 👽?

С моей точки зрения, если сервис регулярно обновляется, то действительно без этого не обойтись, потому что вручную деплоить - это совсем не айс. Однако всюду тащить эти практики тоже неправильно.

〰️ Приведу пример: у нас есть служебный сервис (не тот который является частью приложения, а вспомогательный/инфраструктурный), который обновляется в лучшем случае раз в год. И обычно занимается этим один или два человека. Создание полного пайплайна в этом случае смысла не имеет. Потраченное на него время не окупится.

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

Но все таки, чтобы хотя бы раз в год не пришлось чесать репу: "а как же деплоить то этот сервис??", у меня есть рекомендации:

1️⃣ Обязательно в репозитории с кодом пишите доку в файле README.md, где должна быть инфа: что это такое, как собирать и куда деплоить, что проверить после деплоя.

2️⃣ Желательно иметь некий Makefile для упрощения деплоя с правилами make build, make deploy и тд.

📌 А если вы хотите научиться строить пайплайны и эффективно применять их в процессе разработки современных продуктов, то для вас есть курс СI/CD на практике.

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

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

❗️А от меня, по такому случаю, только сегодня, на все курсы платформы действует полюбившаяся вам акция: 1 + 1 = 3 ❗️

👉 А всем сисадминам, которые думают над сменой профессии в пользу DevOps, советую Программу Наставничества, которая за 6 месяцев сделает из вас уверенных девопсов. На нее сегодня тоже скидочка 5% 😎.

* Чтобы воспользоваться акциями напишите "СИСАДМИН" и список курсов/информацию для наставничества на почту devops@lifeisfile.com

В продолжении темы про CI/CD захотелось порассуждать на тему "Terraform в пайплайне".

О чем собственно я: имеет ли смысл терраформ операции заворачивать в пайплайн для изменения инфраструктуры?
В моей практике я несколько раз видел попытки сделать такое. Самое удивительное, что это даже работало, но как правило недолго (:trollface)

👽 Я могу понять мотивы, которые двигают людей такое делать.
Очень хочется git-ops подхода, когда что-то изменил в коде и оно поехало деплоить инфру само. При этом тебе не надо настраивать креды, токены и прочее, даже не надо иметь локально терраформ нужной версии. Но это в идеале.

На практике, ты же не можешь скомпилировать в голове и предусмотреть абсолютно все. Поэтому отправляешь коммит, там на шаге terraform plan вылезает нечто: либо синтаксис поехал, либо еще что-то. Ок, через пару коммитов вроде бы исправил, но репу уже испачкал кривыми коммитам. Это ладно, дальше доходим до этапа terraform apply, а там уже облачный провайдер вносит свои коррективы, которые на этапе plan еще не известны. И снова начинай дебажить. 👾

👀 В итоге я давно пришел к мнению, что terraform и cicd лучше не смешивать, гораздо удобнее и безопаснее выполнять инфраструктурные изменения с localhost. Единственное, что все-таки человеческий фактор играет роль, и иногда после локального apply люди забывают запушить обновленный код, но это уже решается иными средствами.

〰️ Есть еще интересный на вид инструмент - crossplane, который позволяет управлять инфрой из k8s через кастомные ресурсы. Шанса попробовать его не представилось, но думаю что это может сработать для ограниченного управления ресурсами для нужд разработки.

DevopsTrain

NixOS - дистрибутив Linux, вдохновленный идеей Infrastructure as a code. 

Если вы используете Linux в качестве рабочей системы, то наверняка сталкивались с необходимостью настройки системы под себя после свежей установки 👽. Особенно это критично, если вы используете для работы несколько устройств. В голову приходят идеи вроде ansible или самописных скриптов, которые установят пакеты и накатят конфигурацию. Однако, это не лучший вариант, т.к. он императивный. Вы говорите что нужно сделать, вместо того, что вы хотите получить в итоге.

👉 Рекомендую рассмотреть интересный дистрибутив NixOS, в  основе которого лежит менеджер пакетов Nix с самым большим количеством доступных пакетов среди всех дистрибутивов. Конфигурация вашей системы включая набор пакетов, сетевые настройки, поддержка docker, список пользователей и всего остального задается в файле /etc/nixos/configuration.nix на функциональном языке nix. Придется повозится, чтобы настроить все под себя, но после этого вы просто будете получать готовую к работе ОС всего лишь одной командой:

nixos-rebuild switch

которая создаст изолированную копию системы на основе последней конфигурации и добавит новую версию в загрузчик. Поэтому, если что-то пойдет не так, вы всегда одной командой сможете откатить все изменения. Это еще один очень значимый плюс данной ОС.

На моем горизиноте эта ОС появилась пару лет назад, но только теперь, спустя множество лет работы на традиционных Debian based дистрибутивах, я решил осуществить переезд на нее. Пока еще многое предстоит сделать, но это будет как минимум интересно 👾👀

DevopsTrain

Work-life balance в devops

Немного отвлечемся от сугубо технических тем сегодня. Расскажу о том, почему devops - это лучшая сфера IT, если вы хотите соблюдать здоровый баланс работы и отдыха и при этом остальные отделы компании будут рады 👽😁.

Раньше врачам платили пока человек не болеет, так и девопсам должны платить пока все работает.

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

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

То есть стремление снизить количество работы - это очень здоровое и выгодное для всех занятие.

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

📌 Небольшое объявление: в программе обучения появилась опция оплачиваемой стажировки после прохождения 🤌.

Как создавалась платформа DevopsTrain

В конце 2020 года мне пришла в голову идея создания универсальной платформы для обучения через практику.

Сразу были сформированы требования:

✔️ удобный интерфейс, с упором на практическую часть
✔️ возможность автоматической проверки
✔️ универсальность в плане текстового наполнения, а также в плане бекенда, который проверяет задание
✔️ расширяемость

Исходя из этих требований была разработана архитектура из нескольких сервисов, нарисован макет и составлено задание для frontend разработчика, т.к. я занимаюсь только бекендом и инфрой. Первая версия вышла в начале 2021 года, и включала в себя в качестве пилотного курса - "Kubernetes на практике".

В тот момент у меня не было достаточно ресурсов для продвижения и развития платформы, поэтому временно разработка остановилась, и возобновилась только спустя 2 года.

С марта 2023 года на платформе произошли значительные изменения: улучшена как программная часть, так и образовательная, добавлены новые курсы, доработаны старые. Появился open-source инструмент для проверки заданий - kurator.

👀🔥 Ближайший релиз новой версии состоится в течение 2 недель, и будет включать в себя некоторые долгожданные функции, включая запуск кластера по отдельной кнопке.

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

🤌 Также помните, что купив курс однажды, вы навсегда получаете постоянно обновляемый материал и платформу с удобным поиском. При этом в каждом курсе есть волшебная кнопка "задать вопрос", при нажатии на которую, ваши сообщения поступают напрямую мне. И я на них не без удовольствия отвечаю =)

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

1. Причины переезда
2. Подготовка
3. Переезд
4. Результаты

Итак, начнем с причин, почему я спустя более чем 10 лет работы на Ubuntu в качестве основной десктопной ОС отказался от нее в пользу NixOS:

👉 1. Ubuntu, как мне кажется, катится не в ту сторону.

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

Кстати, про обновления: даже когда ты сам хочешь что-то обновить тут тоже есть проблемы. Я использовал только LTS версии, которые выходят раз в 2 года, поэтому большая часть пакетов устаревает пока новая версия еще не вышла. Это также можно обойти подключив сторонние репозитории или ручной установкой, но такой подход не самый удобный. А еще есть риск, что система при общем обновлении до следующего релиза обновится с ошибками, которые придется каким то образом самостоятельно исправлять. Пару последних обновлений проходили гладко, но все таки всегда боязно это делать. Именно поэтому LTS расшифровывают как Less Time Stressed =).

👉 2. Все перечисленное выше нужно умножать на 2, т.к. у меня 2 ноута для работы: один большой и мощный 17", который я не таскаю в дальние поездки или на короткие вылазки, а второй - легкий 15" чтобы оставаться максимально мобильным. К примеру, в отель или за границу я беру только легкий ноут, он и дешевле и легче, а езжу я нередко.

👉 3. Исходя из 1. и 2. мне стало критически важно иметь систему, которая не умничает и конфигурируется через код. Да, именно код, на каком-то тьюринг-полном языке, а не yaml, чтобы я мог взять и накатить конфигурацию на любой из моих компов и получить идентичную систему со всеми нужными мне конфигами и пакетами.

👉 4. Обновление и вмешательство в настройки не должно ломать систему безвозвратно. И как раз nixOS это умеет: он создает отдельную версию системы в момент пересборки, и я всегда могу откатиться, если что-то пошло не так.

〰️ Кроме nixOS также этим критериям с виду соответствует guix, но она более экзотичная и с меньшим комьюнити и количеством доступных руководств. К тому же использует язык scheme (по сути как emacs lisp), который меня своими скобочками несколько нервирует.

DevopsTrain

Как закон Мерфи работает в devops

Расскажу о том как я провел последнюю неделю августа и начало сентября...

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

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

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

Мда, подумал я.

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

🚬 Другим не менее прекрасным днем я случайно заметил, что у нас в одном из продовых кластеров k8s отвалился vault. А чтобы его поднять нужно знать unseal ключи.

Я пошел спрашивать, но никто мне их не дал. Дело в том, что волт настраивал сотрудник который уже около года как уволился, а сам волт не перегружался 1.5 года. То есть у нас есть черный ящик с секретами для приложения, но достать их оттуда никак не получится 😑.

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

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

Вот так, случается, стоит на пару недель отлучиться сотруднику, как служба, проработавшая 1.5 года, упала с грохотом.

Всегда храните ключи в надежном месте, а костыли подальше от продакшена.

DevopsTrain

Итак, сейчас задену наверное один из самых распространенных страхов тех, кто хочет, но почему-то еще не идет учиться DevOps.

❓А что если после обучения у меня не получится устроиться на работу? 😖

Давно уже не секрет, что качественное резюме + хорошо пройденное собеседование = успешное устройство. Но оба этих кита базируются на навыках и умениях, а не корочках и сертификатах.

К сожалению, в современном мире коммерческие популярные образовательные платформы с миллиардными бюджетами и плохими продуктами, создали мнение, что ВСЕ онлайн-курсы -  низкопробные, и работодетели, да уже и HRы смотрят на них скептически.

Так что просто с пометкой "Прошел курс DevOps инженер с 0 до 300К/наносек" вы маловероятно, что куда-нибудь устроитесь.

❓Так что же делать? - Нарабатывать НА-ВЫ-КИ, скиллы то есть, и именно на них делать упор как в жизни, так и в резюме.

❓Так, а если все популярные платформы пичкают теорией, а для навыков нужна практика?

✔️ Искать ресурсы с интерактивным форматом-тренажером и курсами, где 80% - практика, 20% - легкоусваиваемая теория. А для большей эффективности выбирайте персональный подход, которые подсветит и устранит именно ВАШИ слабые места.

⭐️ Моя Индивидуальная Программа Наставничества - соответствует всем критериям и бустит учеников на уверенный миддл, а то и дальше, да и такой формат обучения вы больше нигде не увидите 😏.

📈 Давайте представим ваши перспективы:

Начинаете мою программу 🔜 проходите курсы 🔜 делаете практический проект 🔜 корректируете резюме 🔜  устраиваетесь на стажировку (могу предоставить), а может и полноценную работу 🔜 зарабатываете 150К+ в месяц (зависит от уровня) 🔜 окупаете обучение за 0.5-2 месяца 💪 🔜  теперь вас ничто не остановит.

Ах, да, сертификат, который получаете после, это не просто Иван Петров прошел курс Петра Иванова, а набор навыков которые теперь у вас есть ✅

📎 На октябрь остались последние места.

Какие еще вопросы разобрать?

Продолжение истории про миграцию на NixOS

Часть 3. Собственно сам переезд.

Интересно, что USB флешки я использую только для установки новой ОС, в остальное время они мне не нужны. Поэтому второй раз за 5 пять лет я сдул пыль с нее и накатил образ NixOS через dd. Спасибо, что не на CD болванку как это приходилось делать лет 15 назад 👽

Загрузился, потыкал next, next, next ... и дело пошло. Минут через 20 перегрузился в свежую ОС и начал приводить в рабочий вид на основе созданного ранее кода конфигурации. Кстати, для себя я нашел удобным положить файлы configuration.nix и home.nix в свой git репозиторий. А чтобы автоматически накатывать внесенные изменения я создал Makefile с правилом make install-switch, которое копирует исходники конфигов из локальной репы в нужное место, а именно в /etc/nixos/, после чего вызывает команду пересборки системы.

☝️Важный момент: несмотря на то, что в случае проблем вы можете загрузиться с более старой конфигурации системы, выбрав пункт в загрузчике, вам все равно нужно думать о том, чтобы иметь возможность откатить сам конфигурационный файл, чтобы вы могли иметь рабочий конфиг в любой момент. И для этого как раз отлично подходит git.

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

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

Через пару недель я повторил операцию на втором ноутбуке и на этом основную часть работы можно считать завершенной 👌

Как вам серия про NixOs?

DevopsTrain

Как я создаю курсы в devopstrain?

Чтобы донести до учащихся материал доступным образом и сопроводить достаточным объемом практики, мною был отработан метод, о котором я хотел бы рассказать.

1️⃣ Формирование списка разделов:

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

🗓 Занимает около недели.

2️⃣ Разработка раздела:

Далее по каждому из разделов начинается работа. Все пункты ниже нужно повторить для каждого раздела. А их бывает от 10 до 25 в моих курсах, суммарно уже более 100 по всем курсам.

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

🗓 Может занять от 1 дня до недели, в зависимости от сложности раздела.

B. Составление плана раздела. Тут уже список тем превращается в структуру, каждый из элементов которого логически связан с соседними. И тут уже важен порядок, т.к. именно по этому плану и будет создаваться материал раздела. Это еще осложняется тем, что нужно придумать практику которая идет по ходу прохождения, а также понять как бекенд будет производить проверку заданий.

🗓 Занимает несколько дней.

C. Написание текста самого курса. Следовать плану уже проще, особенно если он получился подробным, однако оформительская часть отнимает достаточно много времени. Я использую собственную платформу, которая позволяет делать курсы максимально гибкими. И если не хватает каких либо элементов, то дизайнер и фронтендер сделают свою работу и платформа будет доработана. Сам код раздела пишется на YAML, в которых есть кастомные типы для отображения блоков различного функционала. Например: выделение важного, кнопка, faq, ссылки, отображение серверного вывода и многое другое. Также на этом этапе происходит создание схем и диаграмм, чтобы материал был более понятным.

🗓 Этап может занять до 3 недель в некоторых случаях.

D. Создание бекенд части. Бекенд требуется для сохранения состояния прохождения разделов, отображения серверных выводов и, самое главное, проверки ваших заданий. В зависимости от курса, логика сильно отличается, поэтому единого решения тут не придумаешь. Однако, у меня, конечно, есть ряд своих лайфхаков и скриптов для генерации кода.

🗓 Занимает 1-2 дня.

E. Тестирование работы связки курса с бекенд частью, чтобы убедиться, что все работает как задумано.

🗓 Занимает примерно 1 день.

✅ После этих шагов можно переходить к следующему разделу =)

Хотел показать с какой заботой создается каждый курс, и насколько все материалы на моей платформе качественные и эффективные 🙂

Сбои в облачной инфре. На кого валить?

Недавний (очередной) сбой в Яндекс.Облаке намекнул мне на тему поста, в котором попробуем определить зоны ответственности и способы обезопасить себя.

🧨 Аварии случаются, не важно, облако это или сервер в датацентре. Произойти может что угодно: пожар, наводнение, прилет БПЛА, противоправные действия и т.д. Как говорит народная мудрость: There is no cloud, it is just someone's else computer.

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

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

Если ты целиком сидишь в облаке, то у тебя просто нет вариантов в случае аварии, кроме как ждать 👽. Прошу заметить, что тут имеется в виду, что внутри облака у вас построена отказоустойчивая архитектура с множеством зон доступности и  прочими атрибутами высокой доступности. Печаль в том, что это может не помочь. В этом случае вы говорите своим клиентам: извините, мое облако лежит и остается только ждать. Клиентам конечно, пофигу, они просто хотят, чтобы все работало. Но, у вас есть кого обвинить в этом, хотя по факту облажались вы, т.к. полностью доверились одному облаку.

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

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

☝️Взвешивайте риски и обозначайте для себя SLO, так чтобы обещанный SLA для ваших клиентов был в рамках допустимого. Также имейте ввиду, что зона ответственности  облачного провайдера заканчивается определенным периметром, в котором работает ваше приложение, и дальше начинается уже ваша ответственность. К примеру, если после сбоя на виртуальной машине у вас упала БД, но при этом машина запущена и работает, то это уже ваша забота, как восстановить БД.

Про ядро Linux и разработчиков из РФ

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

Все это дело оправдывается какими-то комплаенсами и прочим подобным бредом, якобы это были люди из подсанкционных компаний. Но ядро линукс - это некоммерческий проект и не принадлежит какой-то определенной компании и не относится к какой-либо стране. А то, что мы видим похоже на то, что США так не считают. Они нашли способ надавить на Линуса и других приближенных, так, чтобы испоганить саму идею open source и GPL в частности. Но кажется, что самого Линуса тут не пришлось сильно уговаривать, если посмотреть его реакцию и высказывания. Разочаровал меня Линус, конкретно. Мировое сообщество уже бурлит и негодует из-за данного очень неприятного прецедента.

☝️ На минуточку, разработчики - физ. лица, которые бесплатно добавляли в ядро новый функционал, полезный, в общем-то, всем. Ну, то есть может им и платили за это, но точно не Linux сообщество. Кому в итоге сделали хуже, кто больше потеряет от этого? Правильно, рядовые пользователи линукса со всего мира. Потому что компании, если им это будет нужно, просто форкнут ядро и будут добавлять нужные им патчи в свою ветку, периодически подтягивая из мейнстрима обновления. А вот обратно в мейнстрим их патчи уже не попадут. Гениально 🤯!

📎 Кстати, это не первое нападение на open source за последнее время. Вот тут даже сайт про изъяны Столлмана запилили. Кто это все спонсирует? Думаю понятно.

⌨️ В любом случае, Линукс остается самым большим open source проектом с огромным комьюнити, и альтернатив ему нет. Будем надеяться, что горячка отпустит и все будет хорошо. Пользуясь случаем, напомню, что в devopstrain есть отличный курс по Linux и сетям.

DevopsTrain