Открытая инфраструктура.
В терминологии DevOps есть "инфраструктура" - набор виртуальных машин, баз данных, сетевых настроек, VPN, присоединённых дисков и т.п.
Термин "открытая инфраструктура" никогда не слышал. Есть "открытый код" (open source).
Вообще, смысл в специалистах DevOps следующий.
Когда вы создаёте инфраструктуру для компании/сервиса и т.п., то легко настроить вручную пару виртуальных машин, базу данных, прописать сетевые правила, Firewall.
То когда нужно манипулировать сотнями виртуальных машин, несколькими кластерами с Docker контейнерами и сотнями других ресурсов, приправленных правами доступа, возможностью уплавлять, решать проблемы и перенастраивать, то в картину входит
Infrastructure as a code - подход управления IT инфраструктурой, где DevOps, по сути, описывает кодом (похожим или являющимся языком программирования), как эта структура должна выглядеть, правила её создания и взаимодействия компонентов.
Это позволяет, например, с нуля полностью пересоздать инфраструктуру, отслеживать ресурсы. Если у вас 200 одинаковых виртуальных машин, вы один раз описали её параметры, свойства и т.п. и просто указали "200" в параметре "количество".
Популярный инструмент описания инфраструктуры - Terraform
****набор букв подряд****
Ни одной знакомой аббревиатуры не распознал, наверное человек просто тренировал оральные навыки.
Downtime 13 секунд - сколько времени (за год в данном случае, как я понял), сервис/система была недоступна.
99.9999...9% - параметр надёжности.
Шутки-шутками, но довольно важный параметр, например:
Источник
Кластер - почти всегда подразумевают Kubernetes кластер (https://ru.wikipedia.org/wiki/Kubernetes) - пространство для выполнения Docker (в 99% случаев) контейнеров, которые упоминаются ниже. В кластере можно настраивать какие контейнеры запущены, делать масштабирование, обновление, перезагрузку, направлять на них (контейнеры) траффик извне.
"кластер под каждый дом" - здесь немного высмеивается подход облачных провайдеров, где вы можете выбирать страну, регион, например запад США. Делается это для того, что бы сделать быстрее доступ к сервису пользователей. Например, если взять Netflix, то им разумно видео траффик для европейцев слать с Нидерландов или Гамбурга. Для восточной США из Северной Виргинии.
https://aws.amazon.com/ru/about-aws/global-infrastructure/regions_az/?nc1=h_ls
"меняем несколько переменных в YAML / JSON".
Современные форматы файлов для описания данных определённой структуры. JSON изначально создавался для Javascript (Javascript Object Notation), YAML позже, он лаконичней и выглядит чище (из-за использования табуляций вместо скобок).
Когда можно перенастроить систему, изменив в одном/паре мест параметр, то это признак хорошо организованного продукта (не только DevOps архитектуры).
Infrastructure as a code.
Scaling гейджи. Не знаком с аббревиатурой и вообще непонятно как её записать ? GayG ? GG ?
Scaling - горизонтальное масштабирование сервисов, что бы справляться с увеличенной нагрузкой. В т.ч. некоторые облачные провайдеры предлагают auto-scaling - автоматическое масштабирование в зависимости от нагрузки.
Как пример - у вас интернет магазин феерверков, у вас 1000 посетителей в день, а 29 декабря начинает приходить 100 000. Вам нужно, что бы сайт справился с нагрузкой, грамотный скейлинг помагает решить вопрос.
pilot master ? - хер знает.
Work/life balance - популярная в IT тема. Кто-то фигачит до поздних вечеров, кто-то срывается в 18:00 к семье. На эту тему много холиваров и обсуждений.
CI/CD
https://ru.wikipedia.org/wiki/CI/CD
CI - автоматическая сборка проекта, выполнение тестов и т.п. после того, как разраб залил изменения в главную (или другую) ветку репозитория с изменениями.
CD - автоматический деплой (установка, обновление) продукта после прохождения этапа CI.
То есть, все проверки прошли, обновляем продукт на сервере, железе и т.п. и пользователи видят новую функциональность на сайте (к примеру).
fatality? pipeline - первое слово не встречалось в этом контексте. pipeline - подразумевается конвеер операций, в плане DevOps имеется ввиду обычно CI/CD упомянутый выше. Как и на реальном конвеере, в нашем случае выполняется серия действий, только над продуктом, изменениями. Обычно здесь включены действия компиляции, создание Docker образа, запуск тестов, конфигурация, добавление чувствительных параметров (ключи доступа, пароли).
Kuber - имеется ввиду Kubernetes cluster, описан выше.
Пушишь - заливаешь изменения в код продукта на сервер/репозиторий, некое центральное место, где лежит программный код продукта.
Docker Container
https://ru.wikipedia.org/wiki/Docker
По сути, что-то типа виртуальной машины (ниже), только обрезанная до минимума, не всегда изолированная от внешней операционной системе, в которой живёт.
Основная цель которого (контейнера) - создать пространство библиотек, файлов для выполнения компоненты продукта, где всё настроено именно для этого компонента. Можно сравнить docker container с комнатой, где есть все необходимые инструменты. Например, кабинет стоматологии, рем зона СТО с подъёмником, массажный кабинет и т.п.
Виртуальная машина
Симуляция реального отдельного компьютера, то без отдельного железа. В том смысле, что на одном физическом компе может бегать 10, 20 и т.п. виртуальных машин.
Смысл в том, что раньше арендовали сервера, но их небыстро обслуживать - обновить железо, перезапустить, переустановить систему и т.п. Потом создали виртуальный вариант, где создание такого "компьютера" занимает пару минут. У него выделенная процессорная квота, оперативная память, своя операционка.
ZIP файл - заархивированные файлы в один с целью удобства хранения и уменьшения размера на диске.
Мониторинги. Система отслеживания состояния инфраструктуры - виртуальных машин, Docker конейнеров в кластере, баз данных, загруженности графика, места на диске, состояния приложений. Система передаёт/аггрегирует информацию так, что удобно её наблюдать в одном месте.
Алерты - система отслеживания настроенных параметров, выходя на границы которых мы получаем уведомление об этом. Например, зависло приложение, или перезагрузился Docker конейнер, или время ответа от сервиса превысило 1 секунду (вместо ожидаемых 50мс).
Как сказано в видео, нотификации могут приходить на почту, также в мессенджер, СМС, отображаться в на веб страничке статуса.
Алерты настраиваются в системе мониторинга.
На примере машины - если температура масла выйдет за граничную - у вас зажигается датчик температуры масла.
Логи логов. Хорошо продуманное приложение наполно строками, которые пишут в текстовый файл/на экран/ещё куда-то о всём, что происходит внутри. На примере интернет магазина, разумно логировать:
- посещение странички
- добавление товара;
- покупка;
- транзакция оплаты, удачная неудачная;
- программная ошибка;
- недоступность товара.
Просматривая логи приложения, можно понять что когда произошло, найти где возник сбой или критическое состояние и т.п.
Дежурство.
В DevOps команде часто бывает, что по очереди сотрудники не спят, а мониторят состояние системы, что бы включится, если вдруг произошёл сбой. Конечно, ДевОпс не будет к вам приходить домой, но тем не менее.
