Для администраторов, разработчиков, тестировщиков и инженеров поддержки, которые уже работают в ИТ и идут в DevOps: увидеть, что из базы пора доучивать
Какие темы базы у вас только кажутся закрытыми — узнайте за 20 минут по пятнадцати вопросам с собеседований, а не на самом собеседовании
Вы настраивали кластеры, чинили пайплайны и разбирались с балансировщиком — и всё равно не уверены, что база у вас закрыта. Это не лень и не нехватка опыта: изнутри такие пробелы не видны. Настройка по инструкции выглядит как понимание, пока система работает, и перестаёт им выглядеть на собеседовании или на аварии.
Пятнадцать вопросов, которые задают в эксплуатацию, показывают это за двадцать минут: что у вас закрыто, что вы только считали закрытым и с какого края это закрывать. Без регистрации, без тестов на знание команд и без оценки «от одного до пяти». Показывать результат кому-то не нужно: ответы не сохраняются и не привязываются к вам, анонимно считается лишь, сколько человек выбрали каждый вариант, чтобы улучшать тест.
Вопросы взяты из открытого списка «50 вопросов для DevOps-инженера», который автор ведёт для собеседований с 2018 года и в 2026 году обновил под нынешний стек github.com/olegbukatchuk/50-questions-to-devops. Автор — 19 лет в эксплуатации: cian.ru, aliexpress.ru, mos.ru; проверить его можно по открытому разбору аварии на Хабре habr.com/ru/articles/1078876. Отзывов выпускников у меня нет: курс новый.
Что внутри
Список вместо ощущения.Какие темы базы у вас закрыты, а какие вы только считали закрытыми.
Разбор каждого вопроса.Что он на самом деле проверяет — спрашивают не то, что кажется, — и чем звучит ответ человека, который понимает механику, а чем ответ того, кто настраивал по инструкции.
С какого края закрывать найденное.Принцип порядка и один сквозной пример — почему базу закрывают снизу вверх и что именно понадобилось, чтобы объяснить, почему не поднялся под.
Приём из одной формулировки.Как отличить вопрос про инструмент от вопроса про механику — заранее, по тому, как он сформулирован.
Пройдите проверку сейчас.
Нажмите кнопку — откроется страница с пятнадцатью вопросами. Отвечайте честно: ответы не привязываются к вам. Дальше получите разбор каждого вопроса и список того, что у вас закрыто, а что только считалось закрытым.
В конце проверки будет ссылка на курс. Покупать его не обязательно: список остаётся у вас.
Проверьте свою базу за 20 минут: 15 вопросов, по которым видно, что доучивать
Вы уже работаете в ИТ и доучиваете базу на ходу. Вы настраивали сервисы, чинили пайплайны, поднимали контейнеры, и всё работало. Вопрос один: на какие из пятнадцати вопросов ниже вы ответите, объяснив механику, а на какие только вспомните, как это настраивали.
Эти вопросы не придуманы под курс. Они взяты из открытого списка «50 вопросов для DevOps-инженера», который я веду для собеседований с 2018 года: github.com/olegbukatchuk/50-questions-to-devops. Из пятидесяти я выбрал пятнадцать, на которых проще всего увидеть разницу между «настраивал» и «понимаю». Разборы построены на ответах из того же списка; список открыт, и их можно сверить. В конце я расскажу про курс, который собрал, и он платный. Покупать его не нужно: список, который у вас получится, остаётся вашим в любом случае.
Ответы не сохраняются и не привязываются к вам: список собирается в вашем браузере, вводить ничего не нужно. Анонимно, без cookie и без имени, считается только, сколько человек выбрали каждый вариант: так я улучшаю тест. Достаточно листа бумаги.
Почему это не про лень и не про нехватку опыта
Дыры в базе есть почти у каждого, кто учился на работающих системах, и ставит их среда, а не вы. Вы настраивали по инструкции, где кто-то другой уже принял решения и обошёл грабли. В голове осталась последовательность действий, а не механика под ней. Пока всё работает, разницы не видно. Она проявляется на собеседовании, где спрашивают «почему не поднялось», и на аварии, где инструкция закончилась.
Опасность в том, что такая иллюзия понимания растёт от успехов: каждая удачная настройка добавляет уверенности и вычёркивает тему из списка того, что стоило бы понять. Изнутри её не увидеть. Видно только по внешнему вопросу, на который нечем ответить. Пятнадцать вопросов ниже и есть такой внешний вопрос.
Как проходить
На каждый вопрос уйдёт около полутора минут.
Прочитайте вопрос и, не заглядывая в разбор, честно выберите один из трёх вариантов:
А. Объясню механику: скажу, как это устроено и почему так, а не только как называется.
Б. Знаю, как настроить, но не почему: команды и конфиги помню, а объяснить, что происходит внутри, не смогу.
В. Не отвечу.
Откройте разбор. Сравните свой ответ с двумя образцами: «понимает механику» и «по инструкции».
Если выбрали А, ответьте вслух на проверочный вопрос в конце разбора. Не получилось ответить так, чтобы ответ вытекал из механики, а не из памяти, записывайте Б.
Ключа к проверочным вопросам здесь нет намеренно: их назначение не в заучивании, а в проверке, следует ли ваш ответ из механики. Сверяйте его с разбором выше.
Вопрос 1.Что такое inode и что он хранит?
Разбор, вопрос 1
Что проверяет. Понимаете ли вы, что имя файла и сам файл — разные вещи.
Ответ того, кто понимает механику. Inode — структура файловой системы: тип, права, владелец, размер, временные метки, счётчик жёстких ссылок, указатели на блоки с данными. Имени файла в нём нет: оно лежит в каталоге, который сопоставляет имена номерам inode. Данные удаляются, когда счётчик ссылок равен нулю и файл никем не открыт. Отсюда ситуации «файл удалили, а место не освободилось» и «место есть, а запись падает с No space left on device, потому что кончились inodes».
Ответ «по инструкции». Называет ls -i и stat, говорит «это метаданные файла» и останавливается. На вопрос, почему df и du показывают разное, ответить не может.
Проверьте себя.df показывает, что диск заполнен, а du насчитал вдвое меньше. Почему?
Где закрывается. Блок 02 «Linux: устройство системы и повседневная работа».
Вопрос 2.Что такое swap и когда занятый swap является проблемой?
Разбор, вопрос 2
Что проверяет. Отличаете ли вы «swap занят» от «система задыхается».
Ответ того, кто понимает механику. Swap — область на диске, куда ядро вытесняет редко используемые страницы памяти. В него уходят анонимные страницы (память процессов); страницы файлового кэша просто сбрасываются. Занятый swap сам по себе не проблема: проблема — постоянная подкачка в обе стороны (столбцы si и so в vmstat). Когда память и swap исчерпаны, ядро запускает OOM killer.
Ответ «по инструкции». «Swap используется — значит, памяти не хватает»: правило без механики, которая его объясняет. Различить «занят» и «подкачка идёт в обе стороны» такой ответ не позволяет.
Проверьте себя.free показывает, что свободной памяти почти нет. Это проблема?
Где закрывается. Блок 02 «Linux: устройство системы и повседневная работа».
Вопрос 3.Что показывает Load Average и как понять, много это или мало?
Разбор, вопрос 3
Что проверяет. Знаете ли вы, что именно считает число, на которое смотрите каждый день.
Ответ того, кто понимает механику. Это экспоненциально сглаженное среднее число процессов, которые выполняются или ждут очереди, за 1, 5 и 15 минут. В Linux в него входят и процессы в непрерываемом сне (состояние D), то есть обычно ждущие ввода-вывода. Значение не нормировано: его сравнивают с числом ядер. Высокий LA при низкой загрузке CPU указывает на ввод-вывод. В контейнере LA отражает весь хост.
Ответ «по инструкции». Называет число, но не говорит, что оно считает и с чем его сравнивать. Про состояние D и ввод-вывод не упоминает.
Проверьте себя. LA 40 на четырёх ядрах, CPU загружен на 5 %. Что проверять?
Где закрывается. Блок 02 «Linux: устройство системы и повседневная работа».
Вопрос 4.Какой процесс имеет PID 1 и в каких случаях он не родитель всех процессов?
Разбор, вопрос 4
Что проверяет. Понимаете ли вы, что происходит с процессами и сигналами внутри контейнера, а не только на хосте.
Ответ того, кто понимает механику. PID 1 — первый процесс пространства пользователя, обычно systemd; он запускает сервисы, усыновляет осиротевшие процессы и собирает их коды завершения. Родителем всех он не является в трёх случаях: потоки ядра (потомки kthreadd), контейнер со своим PID namespace и своим PID 1, процесс-subreaper. У PID 1 особое отношение к сигналам: сигнал без явного обработчика игнорируется, поэтому приложение в контейнере может не отреагировать на SIGTERM и будет убито по SIGKILL после таймаута. При shell-форме CMD PID 1 становится /bin/sh, который не пробрасывает сигналы.
Ответ «по инструкции». «Это init, systemd» и всё. Что в контейнере PID 1 — ваше приложение, и из этого следуют таймаут остановки и зомби, не знает.
Проверьте себя. Почему контейнер останавливается ровно 10 или 30 секунд?
Где закрывается. Блок 02 «Linux: устройство системы и повседневная работа» и блок 08 «Контейнеры и Docker».
Вопрос 5.Чем SELinux отличается от AppArmor и как с ними работают, не отключая?
Разбор, вопрос 5
Что проверяет. Видите ли вы в защите механизм, который можно диагностировать, а не только выключатель.
Ответ того, кто понимает механику. Оба — модули безопасности ядра с мандатным контролем доступа: политика ограничивает процесс, даже если обычные права разрешают действие и даже если процесс работает от root. SELinux работает с метками (контекстами) процессов, файлов и портов; AppArmor — с профилями, привязанными к пути исполняемого файла. Отсюда разница: при перемещении файла метка SELinux сохраняется, а для AppArmor файл по новому пути — уже другой объект. Защиту не отключают, а исправляют метки или политику.
Ответ «по инструкции». «Выключить, и заработает». Что именно блокирует доступ и какую метку или политику исправить, не знает.
Проверьте себя. nginx не может прочитать файлы из /data, права на них 755. Что проверять?
Где закрывается. Блок 18 «Безопасность инфраструктуры и DevSecOps».
Вопрос 6.Как работает DNS: что происходит при разрешении имени?
Разбор, вопрос 6
Что проверяет. Видите ли вы цепочку целиком — от приложения до авторитетного сервера — и понимаете ли роль кэша.
Ответ того, кто понимает механику. Приложение обращается к локальному резолверу, тот — к рекурсивному серверу. Если ответа нет в кэше, сервер идёт по иерархии: корневые серверы, серверы зоны верхнего уровня, авторитетные серверы домена. Ответ кэшируется на время TTL. На хосте порядок источников задаёт /etc/nsswitch.conf, серверы и поисковые домены — /etc/resolv.conf. Перед миграцией TTL снижают заранее. В Kubernetes имена разрешает CoreDNS, а ndots:5 и список search-доменов порождают лишние запросы для внешних имён.
Ответ «по инструкции». «Запрос идёт к DNS-серверу, он возвращает IP» и dig. Про кэш и TTL, а значит про то, почему изменение записи доходит не ко всем сразу, не говорит.
Проверьте себя. Запись поменяли час назад, а часть клиентов ходит на старый адрес. Почему?
Где закрывается. Блок 05 «Сети: от кадра до HTTPS».
Вопрос 7.В чём отличие TCP от UDP?
Разбор, вопрос 7
Что проверяет. Понимаете ли вы, что именно гарантирует протокол, и что видно в сети, когда гарантии нарушены.
Ответ того, кто понимает механику. TCP устанавливает соединение (рукопожатие SYN, SYN-ACK, ACK) и передаёт поток байтов с гарантией доставки и порядка: подтверждения, повторная передача, контроль потока и перегрузки. UDP передаёт отдельные датаграммы без гарантий доставки и порядка. TCP гарантирует доставку, но не время: потеря пакета задерживает все данные за ним. Таймауты простоя на балансировщиках и NAT рвут «молчащие» соединения; помогает keepalive.
Ответ «по инструкции». «TCP надёжный, UDP быстрый». Верно, но из такого ответа не следует ничего, что можно проверить на живой системе.
Проверьте себя. Чем в tcpdump отличается обращение к закрытому порту от порта, закрытого firewall с DROP?
Где закрывается. Блок 05 «Сети: от кадра до HTTPS».
Вопрос 8.Что такое TLS и что именно клиент проверяет в сертификате?
Разбор, вопрос 8
Что проверяет. Знаете ли вы, откуда берётся доверие, а не только как получить сертификат.
Ответ того, кто понимает механику. TLS даёт шифрование, целостность и проверку подлинности сторон. Сервер предъявляет сертификат; клиент проверяет цепочку до доверенного удостоверяющего центра, имя и срок действия. Затем стороны вырабатывают общий сессионный ключ, которым шифруется трафик. Типичная ошибка — сервер не отдаёт промежуточный сертификат. Выпуск и продление автоматизируют (ACME, cert-manager), потому что срок действия публичных сертификатов поэтапно сокращается.
Ответ «по инструкции». «Выпустил сертификат, положил в nginx, появился замок». Что проверяет клиент и почему цепочка может быть неполной, не знает.
Проверьте себя. Сайт открывается в браузере, а curl или Java-приложение сообщают об ошибке сертификата. Почему?
Где закрывается. Блок 05 «Сети: от кадра до HTTPS».
Вопрос 9.Какие бывают хранилища данных (блочное, файловое, объектное) и чем они отличаются?
Разбор, вопрос 9
Что проверяет. Понимаете ли вы, чем модели доступа отличаются по сути, а не по названиям продуктов.
Ответ того, кто понимает механику. Блочное отдаёт том как набор блоков, файловую систему создаёт сам клиент; обычно том подключён к одному потребителю, задержки низкие, подходит для баз данных. Файловое отдаёт готовую файловую систему по сети, её используют несколько клиентов одновременно (NFS, SMB). Объектное хранит объекты по ключу и работает по HTTP API (S3): объект нельзя изменить частично, только перезаписать целиком, блокировок файлов нет. Монтировать объектное хранилище как файловую систему под базу данных нельзя.
Ответ «по инструкции». Перечисляет названия (iSCSI, NFS, S3), но объяснить, какое подходит под базу и почему остальные нет, не может.
Проверьте себя. Почему базу данных обычно не размещают на NFS?
Где закрывается. Блок 07 «Приложения и данные: что мы вообще эксплуатируем» и блок 13 «Kubernetes: основы».
Вопрос 10.В чём принципиальное отличие виртуальной машины от контейнера?
Разбор, вопрос 10
Что проверяет. Знаете ли вы, что такое контейнер на уровне ядра, или для вас это «лёгкая виртуалка».
Ответ того, кто понимает механику. Виртуальная машина работает на эмулированном оборудовании под гипервизором и загружает собственное ядро. Контейнер — обычные процессы хоста, изолированные средствами ядра; ядро у всех контейнеров и хоста общее. Namespaces определяют, что процесс видит; cgroups — сколько ресурсов он может занять; capabilities, seccomp, SELinux или AppArmor — что ему разрешено. Образ — набор слоёв, объединяемых overlayfs; форматы стандартизованы OCI. Уязвимость общего ядра позволяет выйти из контейнера.
Ответ «по инструкции». «Контейнер легче и быстрее стартует». Про общее ядро и про то, чем изоляция обеспечивается, не говорит.
Проверьте себя. Что произойдёт с контейнером при превышении лимита памяти? А лимита CPU?
Где закрывается. Блок 08 «Контейнеры и Docker».
Вопрос 11.Чем отличаются Continuous Integration, Continuous Delivery и Continuous Deployment? Какие есть стратегии выкладки?
Разбор, вопрос 11
Что проверяет. Понимаете ли вы, где в конвейере стоит человек и что именно делает откат возможным или невозможным.
Ответ того, кто понимает механику. CI — частые вливания в основную ветку с автоматической сборкой и тестами. Delivery — каждое прошедшее конвейер изменение превращается в артефакт, готовый к выкладке, выкладку запускает человек. Deployment — выкладка в production тоже автоматическая. Стратегии: recreate (с простоем), rolling, blue-green, canary. Артефакт собирается один раз и без изменений проходит все окружения; конфигурация живёт отдельно. Миграции базы должны быть обратно совместимы, иначе откат невозможен.
Ответ «по инструкции». Пересказывает стадии своего пайплайна в GitHub Actions или GitLab CI. Что из этого относится к CI, что к Delivery и почему откат упирается в базу, не различает.
Проверьте себя. Как откатить релиз, в составе которого была миграция базы?
Где закрывается. Блок 09 «CI/CD: непрерывная интеграция и доставка».
Вопрос 12.Как вы понимаете «инфраструктура как код»?
Разбор, вопрос 12
Что проверяет. Видите ли вы за инструментом (Terraform или любым другим) модель: описание, состояние, расхождение.
Ответ того, кто понимает механику. Инфраструктура описана в текстовых файлах, хранится в системе контроля версий и применяется автоматически; изменения проходят review и проверки, как код приложения. Декларативный подход описывает желаемое состояние, императивный — последовательность шагов. Идемпотентность: повторное применение не меняет систему, если она уже в нужном состоянии. Инструмент хранит state; ручные правки приводят к дрейфу, то есть расхождению кода и реальности. State хранят удалённо, с блокировкой и шифрованием.
Ответ «по инструкции». «Пишем Terraform, делаем apply». Что такое state и что случится, если ресурс изменили руками, не знает.
Проверьте себя. Что произойдёт, если кто-то изменил ресурс руками в консоли?
Где закрывается. Блок 12 «Инфраструктура как код: Terraform» и блок 10 «Управление конфигурацией: Ansible».
Вопрос 13.Из каких компонентов состоит Kubernetes и что происходит после `kubectl apply` для Deployment?
Разбор, вопрос 13
Что проверяет. Есть ли у вас в голове путь запроса через кластер, по которому ищут причину, когда под не поднялся.
Ответ того, кто понимает механику. Control plane: kube-apiserver (единственная точка входа), etcd (состояние), kube-scheduler (выбор ноды), kube-controller-manager. На ноде: kubelet, container runtime, kube-proxy, сетевой плагин CNI. Всё построено на циклах согласования: контроллер сравнивает желаемое состояние с фактическим и устраняет разницу. Путь apply: аутентификация, авторизация и admission, запись в etcd, создание ReplicaSet и подов контроллерами, выбор ноды планировщиком, запуск контейнеров kubelet через CRI, настройка сети через CNI, проверки готовности, включение пода в сервис.
Ответ «по инструкции». Перечисляет компоненты по списку, но порядка шагов не знает: «под не поднялся» для него один симптом, а не вопрос «на каком шаге пути остановились».
Проверьте себя. Под завис в Pending. Под в CrashLoopBackOff. Что вы делаете в каждом случае?
Где закрывается. Блок 13 «Kubernetes: основы».
Вопрос 14.Что такое GitOps и чем pull-модель отличается от push?
Разбор, вопрос 14
Что проверяет. Понимаете ли вы, кто и в какую сторону ходит за изменениями, и что при этом происходит с ручными правками.
Ответ того, кто понимает механику. Желаемое состояние декларативно описано в Git, а агент непрерывно приводит реальное состояние к описанному. Изменение — commit через merge request, откат — revert. Push-модель: CI имеет доступ в кластер и сам вызывает kubectl или helm. Pull-модель: агент внутри кластера (Argo CD, Flux) забирает изменения из Git; учётные данные кластера его не покидают, а дрейф обнаруживается и исправляется. Срочные ручные правки агент откатит.
Ответ «по инструкции». «Argo CD следит за репозиторием и выкатывает». Что это даёт и что произойдёт с ручной правкой, не знает.
Проверьте себя. Что произойдёт, если поправить Deployment руками через kubectl edit?
Где закрывается. Блок 14 «Kubernetes: эксплуатация, безопасность и GitOps».
Вопрос 15.Что такое observability и из чего состоит современный стек наблюдаемости?
Разбор, вопрос 15
Что проверяет. Отличаете ли вы «поставил Prometheus и Grafana» от способности по сигналам понять, почему система ведёт себя так.
Ответ того, кто понимает механику. Наблюдаемость позволяет по внешним сигналам понять, что происходит внутри, в том числе в непредусмотренных ситуациях. Мониторинг отвечает на вопрос «сломалось ли», наблюдаемость — «почему». Основные сигналы: метрики, логи, трейсы. Время ответа измеряют перцентилями и гистограммами, а не средним. Алерты строят по симптомам для пользователя и по скорости расхода бюджета ошибок, а не по каждой причине. Кардинальность меток определяет стоимость хранения метрик.
Ответ «по инструкции». Называет стек: Prometheus, Loki, Grafana. Почему среднее время ответа обманывает и по чему настраивать алерты, не знает.
Проверьте себя. Почему нельзя усреднять перцентили с нескольких экземпляров?
Где закрывается. Блок 16 «Наблюдаемость: метрики, логи, трассировки».
Список собирает скрипт. Без JavaScript выпишите номера вопросов по своим ответам сами.
Ваш список
Закрыто
Только считалось закрытым
Не закрыто
Без ответа
Как из ответов собирается ваш список
Выпишите номера вопросов в три колонки по таким правилам.
Колонка
Что в неё попадает
Закрыто
Вы выбрали А и ответили на проверочный вопрос так, что ответ следует из механики
Только считалось закрытым
Вы выбрали Б. Либо выбрали А, но проверочный вопрос не прошёл
Не закрыто
Вы выбрали В
Средняя колонка самая важная: по ней видно, где вы раньше вычёркивали тему из списка «стоит разобраться». Проценты и баллы здесь не нужны: ни «сколько правильных», ни «проходной порог» тест не считает, потому что он не экзамен. Он показывает, какие строки списка у вас настоящие, а какие нарисованы привычкой.
Затем сгруппируйте строки по блокам, указанным в разборах. Если в одном блоке сразу несколько строк из средней или правой колонки, это не пять отдельных дыр, а одна: под ними лежит одна и та же тема.
Тест — выборка, а не вся база
Пятнадцать вопросов не покрывают всей базы. В списке нет вопросов про механику Git, Bash, Python, облаков и Ansible, поэтому их здесь нет. Пустая колонка «не закрыто» не означает, что базы нет, только что в этих пятнадцати местах вы её увидели.
Как отличить вопрос про инструмент от вопроса про механику
Это заметно по формулировке, ещё до ответа. Вопрос про инструмент звучит как «что такое X», «какие Y вы знаете»: на него можно ответить названием. Вопрос про механику звучит как «что произойдёт, если…», «почему…», «чем отличается…»: названием на него не ответишь, нужно «потому что».
Присмотритесь к проверочным вопросам выше. В списке вопрос про GitOps открывается словами «Что такое GitOps?» и выглядит вопросом про инструмент. Но после него спрашивают, что произойдёт с ручной правкой Deployment, то есть про механику. Почти каждый вопрос про инструмент на деле проверяет слой под ним. Поэтому, услышав «что такое X», сразу спросите себя: а что произойдёт, если X сломать? Если ответа нет, это строка из средней колонки.
С какого края закрывать найденное
Принцип один: то, что лежит под инструментом, закрывают раньше самого инструмента. Дыры в верхних слоях почти всегда стоят на дырах нижних, и пока нижний слой пуст, верхний закрывается только до следующей аварии.
Один сквозной пример. Вопрос 13 заканчивается так: «Под завис в Pending. Под в CrashLoopBackOff. Что вы делаете в каждом случае?» Чтобы ответить, мало знать команды. Нужно знать путь запроса через кластер (вопрос 13) и понимать, на каком его шаге остановились. Объяснить причину на этом шаге нельзя, не спустившись ниже: к лимитам памяти и OOM killer (вопросы 2 и 10), к PID 1 и сигналам (вопрос 4), к DNS внутри кластера (вопрос 6). Для того, кто начинает с Kubernetes, каждый шаг остаётся чёрным ящиком. Тот, кто идёт снизу, видит, что внутри.
Это принцип, а не план. В каком порядке и чем закрывать именно ваши строки, зависит от того, из какой роли вы пришли и куда идёте. Тест порядка не даёт, и список его не заменяет.
Что показывает ваш список
Три колонки не оценивают вас, а показывают три разные ситуации.
Закрыто. Эти темы можно вычеркнуть из списка «стоит разобраться». Вы проверили себя вопросом снаружи, а не ощущением.
Только считалось закрытым. Главная колонка. Здесь вы знали, как это настроить, и не знали, что происходит под настройкой. Это и есть иллюзия понимания: она растёт от успехов, потому что каждая работающая настройка добавляет уверенности. Поставила её среда, а не вы: настраивали по инструкции, где решения уже приняли за вас. Изнутри она не видна, потому что ощущение «я это делал» ничем не отличается от ощущения «я это понимаю».
Не закрыто. Тема известна вам как пробел. Это самый удобный случай: искать не нужно.
Если в средней и правой колонках несколько строк из одного блока, это одна дыра, а не несколько: под ними лежит одна тема.
Почему тем же способом это не закрыть
Документация, статьи и доклады отвечают на вопрос «как». Они бесплатны и хороши. Но им нечем ответить на два других вопроса: в каком порядке закрывать именно ваши строки и как узнать, что строка закрыта, а не снова стала казаться закрытой.
Без ответа на них вы повторяете то, что создало иллюзию: проходите по инструкции, видите, что заработало, вычёркиваете тему. Поэтому не хватает не усилий и не времени, а порядка и проверки.
Как устроен курс
Курс собран вокруг этих двух вопросов. Три свойства, и для каждого сказано, что оно значит на деле.
1. База идёт раньше инструментов. До блока про контейнеры стоят 68 уроков из 216. На деле это значит, что к Docker и Kubernetes вы приходите, когда под ними уже разобраны процессы, права, сети и хранилище. Если потом контейнер не поднимается, у вас есть слои, по которым искать, а не один текст ошибки для поиска в сети. «Почему не поднялось» спрашивают и на собеседовании, и на аварии, и отвечать на него приходится из знания слоёв.
2. У каждой домашней работы есть список проверок. 1638 критериев на 216 работ, и каждый проверяется командой, файлом или выводом. На деле это значит, что закончив работу, вы не спрашиваете себя «вроде сделал?», а идёте по списку и видите, какие пункты проходят, а какие нет. Представьте тему, которую вы считали закрытой: на третьем пункте списка выясняется, что объяснить это вы не можете. Минута неприятная, но случается она на вашем стенде, а не на собеседовании. Через месяц к теме можно вернуться с тем же списком и проверить, что она всё ещё закрыта, а не снова стала казаться закрытой. Гадать, закрыта тема или нет, не приходится: проверка либо проходит, либо нет.
3. Практика в трёх средах. Локальный стенд, VPS и Yandex Cloud; каждый урок разобран для всех трёх. На деле это значит, что учиться можно на бесплатном локальном стенде и не трогать рабочий прод, а облако подключать, когда понимаете, что делаете: бюджет с уведомлением ставится в первом блоке, до первых трат.
Чего здесь нет: наставника, потока с дедлайнами и обещания трудоустройства. Проверяют критерии, а не человек. Если вам нужно, чтобы вас вели за руку, это другой продукт.
Ваши строки и блоки курса
Каждый разбор выше заканчивается строкой «Где закрывается»: это блок курса. Выпишите блоки для строк из двух правых колонок. Это ваша часть из 22 блоков.
Тест проверил десять блоков из двадцати двух. Двенадцати остальных он не касался, поэтому полной картины не даёт: вам может понадобиться и часть остального курса, а может не понадобиться. Решать по оглавлению: у каждого блока там написано, что вы будете уметь после него.
Порядок, в котором закрываются эти блоки именно для вас, ваш список не заменяет, и в тесте я его не даю.
Что стоит решить до оплаты
Пять вопросов, на которые лучше ответить заранее, а не после первого платежа.
Подходит ли вам уровень. Курс для тех, кто уже работает в ИТ: предполагается, что вы умеете работать в терминале и понимаете, что такое сервис. Если нет, он вам не подойдёт, и лучше понять это сейчас.
Справитесь ли без наставника. Наставника нет, потока и дедлайнов нет. Урок состоит из 30 минут теории, 30 минут управляемой практики и домашней работы на час-два; примеры к лабораторным лежат готовыми файлами, проверяют критерии. Если вам нужно, чтобы вас вели, это другой продукт.
Хватит ли времени. Четыре урока в неделю — это 8–12 часов. При таком темпе курс занимает чуть больше года, при двух уроках в неделю около двух лет. Темп выбираете вы.
Не бросите ли вы на втором месяце. Первый результат стоит через две недели: собранное рабочее место и стенды (блок 01). К каждой домашней работе есть критерии приёмки, по ним видно, закрыто или нет. Обещать, что получится, я не могу: наставника нет, и дисциплину за вас никто не заменит.
Что будет в конце. Итоговый проект для портфолио, резюме и подготовка к собеседованию (блок 22). Трудоустройства и дохода курс не обещает.
Риск оплаты невелик по устройству: оглавление открыто до неё, подписка помесячная, а список из этого теста остаётся у вас в любом случае.
Если это то, что вы искали
Курс DevOps: 22 блока, 216 уроков. Оглавление открыто целиком, с названиями всех блоков и уроков: devops.bukatchuk.ru/program/. Цена и условия подписки — на странице курса: devops.bukatchuk.ru. Решать вам.
Если не то: список остаётся вашим, закрывать его можно любым способом. Выпускников у курса пока нет, отзывов нет, и я их не придумываю. Автора можно проверить по открытому разбору аварии: habr.com/ru/articles/1078876/ и по списку вопросов, из которого взят тест: github.com/olegbukatchuk/50-questions-to-devops.
Хотите разобрать свой список лично, письменно? Напишите в Telegram @bukatchuk слово «тест»: я читаю и отвечаю сам, в переписке, без созвона. Если тест что-то показал не так или вопрос оказался непонятным, напишите тоже: от этого тест становится лучше.
Олег Букатчук. 19 лет в эксплуатации: cian.ru, aliexpress.ru, mos.ru. Канал: t.me/bukatchuk.
bukatchuk