Jump to content
View in the app

A better way to browse. Learn more.
T.M.I IThub

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Про АЙТИ (About IT)

A blog by IThub in Blogs true ITmans

  • Entries

    30

  • Comments

    3

  • Views

    2598

Entries in this blog

Истории DevOps-инженера

Дев написал «TODO: убрать перед прод-деплоем» — и это пролежало в проде два года

Есть комментарии в коде, которые являются либо руководством к действию, либо тихим криком о помощи. Комментарии с «TODO» — это обещания, которые редко выполняются. Денис, бэкенд-разработчик с которым я пересекался на одном проекте, рассказал мне эту историю как предупреждение. История произошла на его предыдущем месте работы. Был endpoint /api/debug/users — он возвращал список всех пользователей с email, именами и датами регистрации. Без всякой авторизации. Создан во время разработки, чтобы фрон
Истории DevOps-инженера

«Просто перезагрузите сервер» — сказал менеджер. Сервер не поднялся

Есть категория менеджеров, которые искренне верят, что перезагрузка решает все проблемы. Эту веру они несут через годы опыта работы с Windows на домашнем компьютере. Столкновение этой веры с реальностью продакшн-сервера — зрелище одновременно трагическое и поучительное. Эту историю рассказал мне Антон — DevOps в среднем онлайн-ретейлере — в баре, после второго бокала, с видом человека, который прошёл терапию, но ещё не полностью. Была пятница, около шести вечера. Их основной сервер начал подторм
Истории DevOps-инженера

«Удали временные файлы» — и я дропнул нафиг всю базу данных

Это был мой второй месяц на новом месте. Я ещё не до конца понимал архитектуру системы, но уже вполне уверенно держался — учился быстро, читал документацию запоем, задавал правильные вопросы. Тогда я считал, что всё идёт хорошо. Было обычное утро вторника. Технический директор Андрей зашёл ко мне с просьбой, которая казалась абсолютно невинной: — Макс, у нас заканчивается место на prod-db-01. Там где-то есть временные файлы от старых бэкапов, почисти, пожалуйста. — Хорошо, посмотрю. Я зашёл на с
Истории DevOps-инженера

Наш «умный» автоскейлинг в 3 часа ночи раскрутил 847 инстансов и выжрал весь AWS-бюджет за 4 часа

Автоматизация — это прекрасно. Автоматизация без ограничений — это финансовая катастрофа. Я усвоил этот урок очень конкретным способом: через счёт от AWS на $23,000 за четыре ночных часа. Мы настраивали горизонтальный автоскейлинг для API сервиса. Логика была простая: если CPU выше 70% — добавляем инстансы. Работало замечательно в рабочие часы. Что мы не предусмотрели — верхний лимит. Мы установили minReplicas: 2 и забыли про maxReplicas. В Kubernetes HPA это означает «масштабируй сколько нужно»
Истории DevOps-инженера

Я случайно задеплоил в прод конфиг с паролем «test123» — и он там жил три года

Эту историю я долго не хотел рассказывать. Не потому что она страшная — потому что она embarrassing. Но потом я прочитал пост на ithub.uno о том, что культура безопасности строится на открытости, а не на замалчивании. И решился. Было это в 2019-м. Я настраивал GitLab CI для небольшого проекта — сервис рассылки уведомлений. В процессе отладки пайплайна мне нужен был быстрый тест. Я создал файл .env.test с заглушками: DB_PASSWORD=test123, API_KEY=dummy_key_for_testing, SMTP_PASSWORD=test123. Потом
Истории DevOps-инженера

Я удалил продакшн-неймспейс в Kubernetes, нажав не ту кнопку. Даунтайм — 7 минут 20 секунд

Это история о том, почему production дашборды должны быть красного цвета, а staging — зелёного. И почему вкладки браузера надо называть. Пятница. Последний рабочий день перед длинными майскими. Я чистил старый staging кластер Kubernetes — там скопился мусор за несколько месяцев. Namespace за namespace, удаляю deployment'ы, PVC, сервисы. Всё идёт хорошо. В соседней вкладке открыт продакшн дашборд — краем глаза поглядываю на метрики. Не помню точно как это случилось — кажется, я переключился между
Истории DevOps-инженера

Упс... Один git push --force, и полгода работы команды испарились за секунду

Есть команды, которые надо вводить с холодной головой и полным осознанием последствий. rm -rf / — очевидный пример. Но среди разработчиков и DevOps есть своя версия этой русской рулетки — git push --force. Я работал тогда в продуктовой компании — делали SaaS-платформу для управления проектами. Небольшая команда, человек двенадцать, хороший продукт, живые клиенты, нормальный процесс разработки. Мы использовали GitHub, feature-ветки, pull requests, code review — всё как у взрослых. Репозиторий был
Истории DevOps-инженера

Rate limiting заблокировал наш нагрузочный тест, приняв его за DDoS-атаку

Эта история не о катастрофе — она о тех моментах, когда система работает именно так, как ты настроил, но совсем не так, как ты хотел. Мы запускали новый высоконагруженный сервис — рекомендательный движок. Перед запуском нужно было провести нагрузочный тест: убедиться что сервис держит планируемые 500 rps. Я накануне настроил nginx с rate limiting: 100 rps с одного IP, burst 200. Это защита от DDoS. Всё правильно, всё продуманно. На следующий день Вася из QA запустил нагрузочный тест с помощью k6
Истории DevOps-инженера

Скрипт бэкапа работал идеально. Кроме одной детали: он ничего не бэкапил

Самый коварный вид отказа систем — когда всё выглядит как работает, но не работает. Бэкап-система в этом смысле особенно опасна: вы никогда не проверяете её по-настоящему, пока не нужно восстановиться. Мой коллега Паша — педантичный и аккуратный инженер — настраивал резервное копирование для CRM-системы. Написал скрипт на bash: каждую ночь mysqldump, gzip, upload на S3. Всё логируется. При успехе в Slack приходит уведомление «Backup completed: 2.3GB». Скрипт работал восемь месяцев. Каждую ночь в
Истории DevOps-инженера

Горизонтальное масштабирование PHP: всё что вы хотели знать, но боялись спросить

"Просто добавь серверов" — говорят менеджеры. "Это не так просто" — говорим мы. Сегодня расскажу почему не так просто, и как всё-таки сделать так, чтобы было просто. Проблема №1: Состояние сессий Запускаете второй сервер, и пользователи жалуются: "я только что вошёл, а меня снова просит логин". Потому что сессия хранится в файловой системе первого сервера. Правильное решение: Redis-сессии: // app/Config/App.php public string $sessionDriver = 'CodeIgniter\Session\Handlers\RedisHandler'; public st
Истории DevOps-инженера

Мониторинг: от "прод упал, узнали от пользователей" до "прод думает что упасть и уже получил алерт"

Есть два типа DevOps. Первые узнают об авариях от пользователей. Вторые — за 5 минут до того как проблема станет аварией. Я прошёл путь от первого ко второму. Это было долго, больно и неочевидно. Расскажу как. Уровень 0: Никакого мониторинга Это страшное место. Узнаёшь что что-то не так, когда: Пишет пользователь в поддержку Звонит CEO в воскресенье Видишь в Twitter "ваш сайт сломан" Это лечится быстро — после первого воскресного звонка от CEO инстинкт самосохранения быстро мотивирует к дейст
Истории DevOps-инженера

Архитектура очередей: как мы убрали "тормоза" из HTTP-запросов и спасли нервы пользователей

Пользователи не любят ждать. Если кнопка "Отправить" не реагирует три секунды — они уже в Twitter пишут что ваш сайт сломан. Один из самых мощных инструментов для улучшения perceived performance — асинхронная обработка через очереди. Что уходит в очередь В HTTP-запросе должно происходить только то, что нужно пользователю для немедленного ответа. Что НЕ нужно пользователю немедленно: Отправка email Генерация PDF Пересчёт статистики Синхронизация с внешними системами Изменение размеров изображ
Истории DevOps-инженера

Три дня я искал баг в коде — оказалось, сервер жил в другом часовом поясе

Есть баги, которые тихо портят данные и обнаруживаются через месяцы. А есть такие, которые существуют годами, всех раздражают, но никто не может их воспроизвести — потому что они зависят от часового пояса. Та система занималась планированием задач. Пользователь создаёт задачу на «завтра в 10:00» — система её выполняет в нужное время. Казалось бы, простейшая логика. Жалобы начались в марте. Клиенты из Екатеринбурга писали: «задачи выполняются не вовремя, иногда с опозданием на два часа». Я смотре
Истории DevOps-инженера

CI/CD: от "фтп в продакшн" до zero-downtime deploy за 4 минуты

Это история эволюции. Начнём с того момента, когда деплой выглядел так: "Ваня, выгрузи файлики на сервер через FileZilla". И закончим тем, что у нас сейчас — полностью автоматический pipeline с тестами, security checks, zero-downtime deploy и автоматическим rollback. Эра FTP (тёмные времена) Просто знайте: когда я пришёл в эту компанию, деплой выглядел следующим образом: Разработчик локально делал изменения Открывал FileZilla Перетаскивал папку app/ на сервер Молился Это было в 2019 году. Не
Истории DevOps-инженера

Продакшн упал в 23:58 в новогоднюю ночь — и я пропустил бой курантов

В этой индустрии есть негласный закон: если что-то может сломаться в самый неподходящий момент — оно сломается именно тогда. Новогодняя ночь — идеальный момент для проверки этого закона. Я работал в финтех-компании. Мы делали платёжный шлюз. Нагрузка в новый год — одна из пиковых: все переводят деньги, покупают подарки в последний момент, пьют шампанское и одновременно пытаются провести транзакцию. 31 декабря, примерно в 22:00 я сидел у родителей. Оливье, телевизор, ощущение что ты наконец челов
Истории DevOps-инженера

Kubernetes не дал мне сломать прод — и это был лучший баг в моей карьере

Я долго не понимал, почему Kubernetes такой педантичный. Зачем все эти liveness probes, resource limits, PodDisruptionBudget — когда можно просто запустить контейнер и пусть работает? Потом был один день, который изменил моё отношение радикально. Мы деплоили крупное обновление — новая версия API с переработанной системой авторизации. Дата релиза была согласована с бизнесом, пресс-релиз готов, маркетинг ждёт. Всё тщательно проверено на стейджинге. Я жму deploy. Kubernetes начинает rolling update.
Истории DevOps-инженера

PHP 8.3 JIT: я провёл месяц бенчмарков и вот что реально происходит

Когда PHP 8.0 вышел с JIT-компилятором, интернет взорвался. "PHP теперь БЫСТРЕЕ Python!" "JIT изменит всё!" "Переписывайте на PHP!". Заголовки были прекрасны. Реальность — немного иначе. Я потратил месяц на бенчмарки JIT в нашем реальном highload-проекте на PHP 8.3 + CodeIgniter 4.6. Расскажу что нашёл. Без маркетинга, только цифры и контекст. Немного теории (обещаю, коротко) JIT (Just-In-Time compilation) — это компиляция горячего кода в нативные машинные инструкции во время выполнения. В отлич
Истории DevOps-инженера

Я мониторил не тот сервер две недели — пока настоящий тихо умирал

Это история о том, как можно делать всё правильно — и всё равно облажаться. Потому что правильные действия, направленные не туда — это хуже бездействия. Два года назад мы запускали новый микросервис — агрегатор данных для аналитики. Я настроил мониторинг: Prometheus, Grafana, alertmanager, всё по классике. Дашборд выглядел прекрасно. Зелёный. Живой. Метрики бежали в реальном времени. Через неделю аналитики начали жаловаться: данные в отчётах иногда выглядят странно, какие-то пропуски. Я смотрел
Истории DevOps-инженера

Пятница, 23:47. Прод лежит. Я в ванной. Классика.

Привет, коллеги по несчастью. Меня зовут Максим, я продуктовый DevOps с десятью годами шрамов на психике и подгоревшим нервным окончанием там, где у нормальных людей находится чувство покоя. Сегодня я расскажу вам историю, которую в каждой IT-компании мира знают наизусть, но всё равно каждый раз проживают как первый раз. Историю о том, как прод падает именно тогда, когда тебе это меньше всего нужно. Итак. Декабрь. Пятница. Мы только что задеплоили «маленький hotfix» — ну там, буквально пять стро
Истории DevOps-инженера

Kubernetes в продакшне: 18 месяцев, 47 инцидентов и одно просветление

Прежде чем начать, хочу сказать одну важную вещь: я люблю Kubernetes. Искренне. Как любят сложного человека — за глубину, за то, что никогда не знаешь чего ожидать, за то, что каждый день чему-то учишься. И одновременно хочется иногда взять его и... ну, вы понимаете. Восемнадцать месяцев в продакшне с k8s. Сорок семь инцидентов в PagerDuty. Из них тридцать один — "это мы сами виноваты". Остальные шестнадцать — "это k8s виноват, но мы неправильно его настроили". Итого: сорок семь раз мы были вино
Истории DevOps-инженера

Как мы пережили Black Friday: postmortem, который я не хотел писать

Это не та история, которой гордятся. Это история, которую рассказывают тихо, за пивом, другим DevOps'ам — чтобы они не совершили те же ошибки. Но знаете что? Я решил рассказать её громко. Потому что честность важнее репутации, а реальные истории учат лучше, чем придуманные кейсы. Black Friday. Наш e-commerce на CI4. Трафик × 15 от обычного. Что могло пойти не так? Спойлер: всё. Подготовка (которой, как оказалось, было недостаточно) За три недели до BF мы провели "подготовку". По тем временам нам
Истории DevOps-инженера

N+1 запросов: убийца производительности, которого все знают и никто не замечает

Есть проблемы, о которых говорят на каждой конференции, пишут в каждом учебнике и которые всё равно продолжают жить в каждом втором продакшн-проекте. N+1 — именно такая. Это как тараканы: знаешь о них, ведёшь с ними борьбу, думаешь что победил — а потом открываешь новый модуль и привет. Сегодня расскажу про реальный кейс из нашего highload-проекта на PHP 8.2 + CodeIgniter 4. И покажу, как мы с этим боролись системно, а не точечными заплатками. Что такое N+1 на практике Теория все знают. Загружае
Истории DevOps-инженера

Redis Cluster: как я потерял данные, нашёл их обратно и поседел дважды

Есть вещи, которые меняют тебя как специалиста. Первый деплой в прод. Первый incident report, который ты пишешь в 3 ночи. И первый раз, когда ты видишь в логах Redis: CLUSTERDOWN Hash slot not served. Вот это последнее — особенное. После такого начинаешь иначе смотреть на жизнь, на архитектуру и на документацию, которую ты "почти дочитал". Сегодня расскажу про Redis Cluster в highload-продакшне. Без прикрас, без маркетинговых буклетов. Только боль, инсайты и несколько команд, которые спасли мне

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.