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

    20

  • Comments

    3

  • Views

    1043

Entries in this blog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.