🔍 50 фраз, из-за которых ваше резюме летит в корзину

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

➡️ В статье про все клише, которые стоит убрать из резюме

🐸 Библиотека devops'a

🐳 Что такое Dockerfile

Dockerfile — это рецепт сборки Docker-образа. Он описывает, из чего и как собрать изолированную среду — будь то приложение, база данных или целая микросервисная система.

Всё строится из простых инструкций:

FROM golang:1.22-alpine   # базовый образ
WORKDIR /app              # рабочая директория
COPY . .                  # копируем файлы
RUN go build -o main .    # собираем проект
CMD ["./main"]            # команда запуска

• FROM — задаёт базовый слой (например, ubuntu, node, golang)
• WORKDIR — где выполняются команды
• COPY / ADD — добавляют файлы внутрь контейнера
• RUN — выполняет команды во время сборки
• CMD / ENTRYPOINT — определяют, что запустится при старте контейнера
• EXPOSE — сообщает, какие порты слушает контейнер
• ENV — задаёт переменные окружения

1. Docker читает Dockerfile построчно.
2. Каждая команда создаёт слой в образе.
3. Эти слои кэшируются — поэтому повторная сборка идёт быстрее.
4. Готовый образ можно запускать как контейнер, передавая параметры и окружение.

Что такое слой

Каждый слой — это snapshot изменений файловой системы.

На нашем примере:

1️⃣ FROM golang:1.22-alpine

Docker берёт готовый базовый образ с Golang и Alpine Linux.
Это уже несколько слоёв, собранных кем-то раньше:

• минимальная система (Alpine)
• системные библиотеки
• установленный Go-компилятор

Эти слои загружаются из Docker Hub и кэшируются локально.
Все они read-only — вы их не меняете, просто используете как основу.

2️⃣ WORKDIR /app

Создаётся новый слой, где внутри файловой системы появляется папка /app.
Теперь все последующие команды будут выполняться именно в ней.

Даже если она пуста, Docker фиксирует это изменение файловой структуры как отдельный слой.

3️⃣ COPY . .

Docker копирует все файлы из текущей директории (build context) в /app контейнера.
Результат — ещё один слой, где лежат исходники вашего проекта.

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

4️⃣ RUN go build -o main .

Docker запускает внутри контейнера команду go build.
Она создаёт бинарник main прямо в /app.

После завершения — создаётся новый слой,
в котором лежит тот самый скомпилированный файл.
Предыдущие слои (с исходниками, библиотеками и т.д.) остаются неизменными.

5️⃣ CMD ["./main"]

Это не создаёт новый слой.
CMD добавляет метаданные — какую команду Docker должен запустить,
когда контейнер стартует docker run image_name.

Dockerfile — это сердце контейнеризации. Без него не было бы reproducible-сборок, dev/test окружений и того самого works on my machine.

🐸 Библиотека devops'a

#арсенал_инженера

🇮🇹 В Италии есть свой X11

На реддите пользователь внезапно нашёл логотип X11 / Xorg — системы, через которую десятилетиями проходили все окна Linux.

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

💬 А вы встречали логотипы или названия IT-компаний в реальной жизни — не на конференциях, а случайно?

🐸 Библиотека devops'a

#холиварня

💬 Различия между Liveness, Readiness и Startup Probes

Одним из популярных вопросов на собесе является вопрос про разницу между Liveness, Readiness и Startup пробы. Давайте разберёмся, что каждая из этих проб делает, когда и как их использовать.

1. Что такое Liveness Probe

Цель: проверка, жив ли контейнер. Если контейнер не отвечает на пробу, Kubernetes перезапустит его.

Когда использовать: всегда используйте Liveness пробу, чтобы обнаружить ситуации, когда приложение зависает или перестаёт функционировать. Это поможет Kubernetes перезапустить контейнер и избежать длительных сбоев.

Пример: если ваше приложение зависает из-за дедлока или других внутренних проблем, Liveness проба поможет автоматически перезапустить контейнер.

2. Что такое Readiness Probe

Цель: проверка готовности контейнера принимать трафик. Если контейнер не готов, Kubernetes не будет направлять трафик к этому контейнеру.

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

Пример: если веб-серверу нужно 10 секунд для подключения к базе данных, настройте Readiness пробу, чтобы Kubernetes не отправлял запросы до завершения этого процесса.

3. Что такое Startup Probe

Цель: проверка того, успешно ли контейнер стартовал. Полезно для контейнеров с долгим временем старта.

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

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

Опции конфигурации проб

1. initialDelaySeconds

Указывает время, которое Kubernetes будет ждать после старта контейнера до первой проверки.

Пример: если вашему приложению нужно 10 секунд для начала работы, установите initialDelaySeconds: 10.

2. periodSeconds

Интервал между проверками после первой.

Пример: если вы хотите проверять контейнер каждые 30 секунд, установите periodSeconds: 30.

3. failureThreshold

Указывает, сколько последовательных неудачных проверок Kubernetes допускает до того, как перезапустит контейнер.

Пример: если ваше приложение иногда теряет соединение, установите failureThreshold: 3, чтобы избежать перезапусков при временных сбоях.

4. timeoutSeconds

Время, которое Kubernetes будет ждать от контейнера, прежде чем считать проверку неудачной.

Пример: если приложение может задерживаться с ответом, установите timeoutSeconds: 5, чтобы дать достаточно времени на обработку запроса.

Как избежать конфликтов при настройке проб

Если настроены все три типа проб, важно убедиться, что они не конфликтуют. Например, если настроена Startup проба, то Liveness и Readiness пробы будут выполняться только после её успешного завершения. Это помогает избежать перезапуска контейнера на этапе инициализации, если приложение запускается медленно.

🐸 Библиотека devops'a

#задача_со_звёздочкой

⚡️ Grafana на ObservabilityCON

На ObservabilityCON 2025, прошедшей с 7 по 9 октября, Grafana Labs представила несколько новинок:

• ИИ-агент, который помогает писать запросы, строить дашборды и расследовать инциденты с использованием естественного языка.

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

• Добавлены новые источники данных, такие как MongoDB, Oracle, и Snowflake.

• Расширенные функции управления доступом и соответствия требованиям для корпоративных клиентов.

➡️ Блог разрабов

🐸 Библиотека devops'a

#пульс_индустрии

🐸 Библиотека devops'a

#пятничный_деплой

💻 Вакансия недели

У нас в канале много интересных вакансий. Вот одна из них:

Нужен Senior SRE с опытом администрирования Linux от трёх лет. Обязательно: опыт администрирования MySQL и Kubernetes. Удалёнка и от 300 000 ₽.

🐸 Библиотека devops'a

#вакансия_недели

🐳 Как работает Docker изнутри

Docker Client отправляет команды docker build, docker pull, docker run Docker демону, который работает на Docker хосте. Демон отвечает за создание и запуск контейнеров, а также за загрузку образов из Docker Registry, например, Docker Hub или других репозиториев.

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

🐸 Библиотека devops'a

#архитектура_на_салфетке

🧩 Microsoft Defender перепутал версии SQL Server

Microsoft подтвердили баг, из-за которого встроенный Microsoft Defender начал ошибочно помечать SQL Server 2017 и 2019 как End-of-Life.

Алгоритм решил, что поддержка закончилась, хотя в реальности SQL Server 2019 жив до 2030 года, а 2017 — до 2027.

🐸 Библиотека devops'a

#пульс_индустрии

🐸 Библиотека devops'a

#пятничный_деплой

🖥 JSON Crack — визуализируйте данные

JSON Crack — это сервис сразу превращает данные в наглядное дерево: можно раскрывать узлы, искать нужные поля и экспортировать схему как изображение. Всё работает прямо в браузере — без отправки данных на сервер.

Кроме JSON поддерживаются YAML, XML, CSV и TOML. Есть валидатор, конвертер и генератор типов для TypeScript и Go. Отличный инструмент, если нужно быстро разобраться в структуре API или объяснить коллегам, как устроен ответ сервера.

➡️ Визуализировать свой JSON

🐸 Библиотека devops'a

#арсенал_инженера

📰 Итоги недели

О чем спорили и размышляли.

— Вышел OpenSSH 10.2

Исправления критических ошибок, влияющих на использование ControlPersist и поддержка PKCS#11.

— Обновления дистрибутивов

— 50 фраз, из-за которых ваше резюме летит в корзину

— Grafana на ObservabilityCON

— Microsoft Defender начал ошибочно помечать SQL Server 2017 и 2019 как End-of-Life

🐸 Библиотека devops'a

#дайджест_недели

⚙️ Структурный diff, который понимает код

Разбор изменений скриптов и быстрая интеграция pull request-ов — часть ежедневной рутины. Классические diff-утилиты путаются в кавычках, списках и многострочных изменениях, а ручное разрешение конфликтов ­чаще раздражает, чем помогает.

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

Он построен на базе tree-sitter — парсера, поддерживающего десятки языков программирования, и анализирует файлы на уровне синтаксиса.

Пример использования:

difft simple_1.js simple_2.js

или для git:

difft git main feature-branch

➡️ Сравнить файлы

🐸 Библиотека devops'a

#root@prompt

🛠 Bun 1.3 упрощает деплой JS-приложений

Bun 1.3 решает несколько проблем, с которыми DevOps сталкивается при работе с Node.js-приложениями. Разберём, какие фичи добавили.

Главная фича для деплоя — компиляция в standalone executable. Вместо образа с Node.js, npm install и гигабайтом зависимостей получаете один бинарник:

bun build --compile ./app.ts --outfile myapp

Также кросс-компиляция из коробки, собираете на CI под все платформы:

bun build --compile --target=linux-x64 ./app.ts --outfile app-linux
bun build --compile --target=darwin-arm64 ./app.ts --outfile app-macos
bun build --compile --target=windows-x64 ./app.ts --outfile app.exe

Не нужно тащить драйверы для PostgreSQL, MySQL, SQLite и Redis. Всё встроено, zero dependencies:

import { sql, redis } from "bun";

await redis.set("cache_key", data);
const users = await sql`SELECT * FROM users`;

В версии 1.3 снизили потребление памяти на 10-30% для популярных фреймворков (Next.js -28%, Elysia -11%). Idle CPU тоже оптимизировали — приложение не жрёт процессор в режиме ожидания.

➡️ Подробнее про обновление

🐸 Библиотека devops'a

#пульс_индустрии

У библиотеки программиста тоже есть свой Х.

Настоятельно рекомендуем залогиниться прежде чем заходить в наш канал, ведь Х скрывает посты от случайных пользователей

🐸 Библиотека devops'a

#пятничный_деплой

🔥 Держим приложение всегда готовым к запросам

Холодный старт — это когда платформа создаёт новый контейнер для вашей функции с нуля. Надо загрузить код, поднять рантайм, инициализировать библиотеки, открыть соединения. Всё это может занять от 500 мс до нескольких секунд.

Проблема не в том, что это происходит — это нормально. Проблема когда это происходит прямо во время запроса пользователя.

Тёплый пул держит нужное количество инстансов постоянно прогретыми. Платформа их уже запустила, код загружен, зависимости инициализированы. Запрос попадает в уже работающий контекст.

Настройка в Kubernetes

Базовый Deployment с фиксированным числом реплик:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3  # всегда 3 пода
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: registry.example.com/api:latest

С автомасштабированием, но с минимумом подов:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  minReplicas: 3      # минимум всегда тёплых
  maxReplicas: 20     # максимум при нагрузке

K8s держит указанное количество подов всегда запущенными. Если приходит больше запросов — HPA создаёт дополнительные поды. Но первые запросы всегда попадут в прогретые.

Сколько реплик держать

• 2-3 реплики — если у вас стабильный трафик
• 5-10 реплик — для критичных API с непредсказуемыми всплесками
• По реплике на availability zone — если распределяете нагрузку по зонам

Не держите 50 реплик на всякий случай. Смотрите в метрики:

kubectl top pods -l app=api

Тёплый пул — это способ сделать так, чтобы пользователи не замечали холодные старты.

🐸 Библиотека devops'a

#арсенал_инженера

👀 Смотреть на весь файл сразу

Tino — простая CLI-тулза, которая показывает весь текстовый файл целиком в одном окне терминала, разбивая его на колонки.

Чтобы её использовать нужно лишь написать в терминале:

tino имя_вашего_файла

Проект был написан на чистом Си и не зависит ни от каких библиотек. Для такого уровня нужны фундаментальные знания, которые есть на нашем интенсиве по архитектуре. До конца октября ещё и со скидкой.

➡️ Попробовать Tino

🐸 Библиотека devops'a

#арсенал_инженера