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

    1013

Entries in this blog

Истории 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-инженера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Немножко о фронтенде, основные моменты проясним в этом блоге

Представьте: вы сидите за монитором, на экране уже есть кнопки, текст, картинки. Всё вроде работает. И тут менеджер кидает новую фичу: «Сделай модалку с формой для отзывов». Казалось бы — мелочь. Но как это сделать так, чтобы не сломать весь фронтенд? Давайте разберём, что реально происходит, когда фронтенд-разработчик «ковыряет» код на React. 💻 Фронтенд – это то, что видит пользователь Фронтенд — это интерфейс, всё, что юзер видит и трогает: кнопки, меню, формы, анимации. Фронтенд-разработчик н
Помошь в собесах

Как пройти техническое собеседование и не выглядеть как студент, который учил шпаргалки

Технические интервью пугают не сложностью задач, а неопределённостью. Кажется, что могут спросить абсолютно всё — и поэтому многие начинают готовиться хаотично: читают десятки статей, пересматривают сотни видео, зубрят определения. Результат? Знаний больше, а уверенности — меньше. На самом деле, техническое собеседование устроено гораздо проще и предсказуемее, чем кажется. Если понимать, что проверяют на самом деле, подготовка превращается из хаотичного марафона в точечный и эффективный процесс.
Для фронтендера

Pet-проекты для frontend-разработчика: идеи для портфолио

Если ты начинающий frontend-разработчик, рано или поздно сталкиваешься с вечным вопросом: «Знаний много, а опыта работы нет. Что делать?» Ответ простой — делать pet-проекты. Что такое pet-проект и зачем он нужен Pet-проект — это личный или учебный проект, который ты создаешь самостоятельно, чтобы: Закрепить знания HTML, CSS, JavaScript. Показать, что умеешь работать с фреймворками (чаще всего React). Продемонстрировать мышление разработчика, а не просто умение сверстать экран. Для работодател
Ржака IT

Top DevOps Jokes That Hit Way Too Close to Home

DevOps is not a profession. It’s a state of mind where you’re fixing prod, explaining that it “never actually went down,” and writing a postmortem blaming an “unpredictable external factor” — all at the same time. If programmers joke about code, DevOps joke about pain. About nights. About alerts. About “it worked fine on staging.” Below is a collection of the funniest and at the same time painfully accurate DevOps jokes loved by people in the industry. If you’re laughing — you’re one of us. If y
Ржака IT

Топ угарных DevOps-шуток, которые пря до боли жиза...

DevOps — это не профессия. Это состояние души, когда ты одновременно чинишь прод, объясняешь, что он «не падал», и пишешь постмортем, в котором виноват «непредсказуемый внешний фактор». Если программисты шутят про код, то DevOps шутят про боль. Про ночь без сна. Про алерты всюду. Про «всё работало на стейдже». Ниже — подборка самых смешных и одновременно правдивых DevOps-шуток, которые любят люди из индустрии. Если ты смеёшься — значит, ты в теме. Если не смеёшься — подожди, скоро дойдёт. 1. Dev
Ржака IT

Top 30 Programmer Jokes (ENG Ver)

Many people believe that programmers are socially awkward introverts who only talk to their monitors and survive on coffee. That’s not entirely true. Programmers are people with rich inner worlds, extreme focus on goals, and a very specific sense of humor 🤓 Yes, their jokes aren’t always clear to those far from IT — but that’s the point. They’re funny, painfully honest, and sometimes frighteningly accurate. So here it is: the top 30 programmer jokes that will make you either laugh, think… or qui
Ржака IT

Топ-30 шуток про программистов

Многие уверены, что программисты — замкнутые интроверты, которые разговаривают только с монитором и питаются кофе. На самом деле это не так. Программисты — это люди с богатым внутренним миром, высокой концентрацией на цели и очень специфическим чувством юмора 🤓 Да, их шутки не всегда понятны тем, кто далёк от IT, но именно в этом и суть — они смешные, болезненно правдивые и иногда пугающе точные. Итак, встречайте: топ-30 шуток о программистах, после которых вы либо засмеётесь, либо задумаетесь,

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.