INZHENERKA.TECH

🦀 Один unwrap() — и интернет начал падать. Эпизод №3 18 ноября 2025 года интернет начал вести себя странно. Сайты переставали открываться. API возвращали HTTP 5xx. Сервисы Cloudflare то оживали, то снова выходили из строя. Инженеры заподозрили DDoS-атаку. Но хакеров не было. Причиной стал обычный SQL-запрос. Что запустило цепную реакцию? В 11:05 Cloudflare изменила права доступа в ClickHouse для повышения безопасности. Но один SQL-запрос выбирал метаданные из system.columns, не указывая конкретную базу данных. Раньше это работало. После изменения прав запрос стал возвращать дополнительные строки из другой схемы. Данные начали дублироваться. На их основе каждые пять минут генерировался конфигурационный файл для Bot Management, которая отличает пользователей от ботов. Файл автоматически распространялся по сети Cloudflare. Почему интернет то падал, то восстанавливался? Обновление ClickHouse шло постепенно. На одних узлах запрос возвращал правильные данные, на других — дублированные. Каждые пять минут в сеть могла отправиться рабочая или некорректная конфигурация. Система падала, восстанавливалась и снова падала. Поэтому инженеры заподозрили атаку. А при чем здесь Rust? Новый прокси-сервер Cloudflare — FL2 — использовал Bot Management. Обычно модель работала с 60 признаками при лимите 200 признаков. Но новый файл содержал более 200 записей. Здесь ошибка добралась до Rust. При обработке данных возник Err. В Rust тип Result<T, E> различает успешное выполнение Ok и ошибку Err. Но код использовал метод unwrap(). Если результат — Ok, метод извлекает значение. А если Err? Происходит panic. В логах Cloudflare появилась строка: called Result::unwrap() on an Err value Вместо обработки ошибки прокси начал возвращать HTTP 5xx. Старая версия прокси тоже пострадала: некоторые запросы получали оценку бота 0 и могли блокироваться защитой. Чем все закончилось? Инженеры остановили распространение некорректного файла и восстановили рабочую конфигурацию. К 14:30 UTC основной трафик восстановили. Полностью системы вернулись к нормальной работе в 17:06 UTC. Несколько часов сбоя. И всё началось с цепочки обычных решений: изменение прав доступа, SQL-запрос без фильтра, выросшая конфигурация, необработанный Err. Чему эта история учит разработчиков? 1. Result — не формальность. Используйте unwrap() только там, где паника допустима. 2. Конфигурация — тоже входные данные. Проверяйте ограничения, структуру и значения до применения. 3. Тестируйте интеграции. Изменение в базе данных может вызвать сбой в другом компоненте системы. 4. Продумывайте обработку ошибок. Некорректная конфигурация не должна выводить из строя критически важный сервис. Rust защищает от многих ошибок работы с памятью. Но от неверных предположений разработчика не защищает ни один язык. Поэтому Rust важно не просто знать, а уметь писать код, который выдерживает неожиданные ситуации. Именно для этого мы создали практический тренажер Rust с нуля. Здесь вы не просто читаете про Result, Option и обработку ошибок, а практикуетесь: пишете код, решаете задачи и разбираетесь, почему одно решение работает, а другое приводит к ошибке. Потому что цена ошибки в тренажере — еще одна попытка. А в продакшене — иногда часы недоступности сервиса. ➡️ Выбрать курс со скидкой 30%

🔥 До 11 ноября включительно на тренажёр Rust и все остальные курсы действует скидка 30% по промокоду BOO30.

43 лишние секунды, которые стоили целой лунной станции Невыдуманные истории. Эпизод № 2: «Луна-25» В космосе катастрофы происходят беззвучно... 19 августа 2023 года. Российская автоматическая станция «Луна-25» уже преодолела сотни тысяч километров, добралась до Луны и готовилась к одному из самых ответственных этапов своей миссии - переходу на предпосадочную орбиту. Все должно было решиться за 84 секунды. Двигатель включился. Прошло 84 секунды. Но он не выключился. Работал дальше. И дальше. Остановился только на 127-й секунде. Казалось бы, каких-то 43 лишних секунды. В обычной жизни за это время едва успеешь налить себе кофе. В космосе их оказалось достаточно, чтобы потерять целую станцию. Пупупу... Что произошло с бортовой системой? Бортовая система управления должна вычислить необходимое изменение скорости по данным измерительных приборов и в нужный момент отдать команду на отключение двигателя. А она получала нули 🤡 По предварительным выводам Роскосмоса, в приборе БИУС-Л не включился блок акселерометров. Двигатель продолжал работать, а система управления не могла определить, что необходимое изменение скорости уже достигнуто. Команда на отключение по расчетному изменению скорости так и не была сформирована. В итоге двигатель выключился по временной уставке. 127 секунд вместо 84... Почему не включились акселерометры? Представьте систему, в которой команды имеют разные приоритеты исполнения. Но что произойдет, если несколько команд с разными приоритетами окажутся в одном массиве данных? По опубликованной Роскосмосом версии, именно такая ситуация могла стать наиболее вероятной причиной сбоя. Распределение команд по массивам носило вероятностный характер. Иными словами, ошибка могла проявляться не всегда. Сегодня определенная последовательность команд отрабатывает корректно. Завтра - та же операция при другом распределении команд приводит к нештатному результату. Для разработчиков embedded-систем и тестировщиков это особенно неприятный сценарий. А потом она проявляется именно тогда, когда права на ошибку уже нет. Чем все закончилось? Дополнительные секунды работы двигателя изменили траекторию станции. Вместо запланированной предпосадочной орбиты «Луна-25» оказалась на нерасчетной незамкнутой траектории. Аппарат столкнулся с поверхностью Луны. Миссия, к которой готовились годами, закончилась ещё до мягкой посадки. Никаких хакеров. Никакого злого умысла. Никакой мистики. Чему она может научить инженеров? 1. Проверяйте не только штатные сценарии. Команды с разными приоритетами и их сочетания могут приводить к неожиданным результатам. 2. Не доверяйте всему безоговорочно. Отсутствие данных от датчика и реальное нулевое измерение - не одно и то же. Проверяйте, как система реагирует на подобные ситуации. 3. Всегда тестируйте защитные механизмы. Что произойдет, если основной алгоритм не сможет завершить операцию? Как сработает резервное условие отключения? 4. Моделируйте редкие сбои. Fault injection, нестандартные последовательности команд и стресс-тестирование критического ПО помогают выявлять проблемы, которые легко пропустить в штатных условиях. Самое страшное в этой истории даже не столкновение с Луной. А то, насколько незаметным может быть начало катастрофы. Иногда она начинается не со взрыва, не с красного экрана и даже не с сообщения об ошибке. Иногда она начинается с нуля в данных, который система не смогла правильно обработать.

🔥 А до 11 ноября включительно на все курсы действует скидка 30% по промокоду BOO30

Учитесь на чужих ошибках — это гораздо дешевле, чем на своих. ➡️Выбрать курс со скидкой -30%

👻 45 минут. Минус $460 миллионов. И ни одного хакера. Эпизод № 1: Релиз, который стоил почти полмиллиарда долларов. 1 августа 2012 года в американской компании Knight Capital произошёл один из самых дорогостоящих программных сбоев в истории биржевой торговли. Всё началось с обновления торговой системы. Компания готовилась к запуску новой функциональности для Нью-Йоркской фондовой биржи. Инженерам необходимо было обновить систему маршрутизации заявок SMARS, работавшую на восьми серверах. Но новый код попал только на семь из восьми серверов. В системе оставался старый алгоритм Power Peg, который перестали использовать ещё в 2003 году. При разработке новой функциональности инженеры повторно использовали управляющий флаг, который раньше запускал Power Peg. На семи обновлённых серверах этот флаг активировал новую логику. А на восьмом, где остался старый код, - запустил давно забытый алгоритм. Но это была вершина айсберга.  Ещё в 2005 году разработчики изменили расположение функции, которая отслеживала количество исполненных акций по заявке. После этого старый Power Peg не протестировали повторно. В результате при его случайной активации система перестала корректно контролировать, когда нужно прекратить отправку заявок. Представьте: Клиент отправляет заявку на покупку акций. Система разбивает её на небольшие дочерние заявки и направляет их на биржу. Заявка исполнена. Другая часть торговой платформы это уже знает. Но SMARS не получает необходимую информацию. Алгоритм продолжает отправлять заявки. И снова. И снова. ☠️ Ну и на десерт. Ещё до открытия торгов внутренняя система Knight Capital отправила сотрудникам 97 автоматических писем с сообщением Power Peg disabled. Но эти письма не были настроены как критические оповещения, а сотрудники обычно не проверяли их в режиме реального времени. Проблему не обнаружили до открытия биржи. огда торги начались, ситуация быстро вышла из-под контроля. Всего за 45 минут: - 212 исходных клиентских заявок привели к отправке миллионов дочерних заявок. - Произошло более 4 миллионов исполнений сделок. - Общий объём сделок превысил 397 миллионов акций. - Убыток компании составил более $460 миллионов. Инженеры пытались исправить ситуацию прямо во время торгов. В какой-то момент они удалили новое обновление с семи исправно работавших серверов. Но попытка отката только усугубила проблему. Теперь старый алгоритм Power Peg мог активироваться и на этих серверах.  🎃 Страшно? А ведь это невыдуманная история! Ни хакерской атаки, ни мистики. Просто цепочка инженерных ошибок: неполный деплой, забытый legacy-код, отсутствие достаточных проверок, неэффективный мониторинг и неудачный rollback. Прочитать полное расследование можно тут В честь Хэллоуина мы запускаем серию «Невыдуманные истории» - о реальных IT-катастрофах, технических провалах и инженерных решениях, которые обошлись компаниям в миллионы. Новые истории будут выходить через день до 11 ноября включительно. 👻

🔥 Скидка 30% на все курсы и тренажёры по промокоду BOO30 действует до 11 ноября включительно.

Учитесь на чужих ошибках — это гораздо дешевле, чем на своих 😉️️️️️️ ➡️Выбрать курс со скидкой 30%

🐧 Пользуетесь Linux — а насколько хорошо понимаете, что происходит внутри? Подготовили 3 вопросы с подвохом 🤔 А если захочется копнуть глубже, у нас есть два курса Программирование Linux на C и Разработка модулей ядра Linux А теперь погнали 😮

Прод упал за 40 минут до демо. Что делает тимлид? В Telegram чаще всего выбирали разделить команду, а в Threads — откатить релиз. Вот результаты нашего опроса на момент скриншотов: Но ответы показывают четыре направления действий. Вопрос не только в том, какое выбрать, — важно, в какой последовательности и при каких условиях действовать. 1. Откатить релиз: логично, но не вслепую В комментариях прозвучали два важных аргумента. Первый: падение может быть не связано с релизом, а выполненные миграции могут осложнить откат. Второй: если сбой совпал с выкладкой, последние изменения стоит проверить в первую очередь. Эти мысли не противоречат друг другу. Релиз — приоритетная гипотеза, но ещё не установленная причина. Поэтому проверяем: — совпало ли начало ошибок с изменениями; — затронуты ли обновлённые компоненты; — есть ли проверенный сценарий отката; — совместима ли предыдущая версия приложения с текущей базой. Миграция сама по себе не запрещает откат. Важен характер изменений: например, если удалили столбец, который нужен старой версии приложения, возврата старого кода недостаточно. Если признаки указывают на релиз и безопасный откат предусмотрен — действуем. Не нужно ждать полного расследования причины. 2. Назначить incident lead: организовать восстановление Из предложенных вариантов это наиболее надёжная отправная точка при неизвестной причине сбоя. Нужен человек, который координирует действия: кто проверяет гипотезы, кто вносит изменения и когда команда сверяется по результатам. Это может быть сам тимлид — отдельная должность не обязательна. Приостанавливаем несогласованные изменения, определяем масштаб сбоя и начинаем короткую диагностику. Недоступного senior-разработчика не ждём два часа: работаем с доступными специалистами и используем принятый порядок эскалации. Десять минут — контрольная точка, а не обязательная пауза перед восстановлением. Если безопасное решение понятно раньше, применяем его раньше. 3. Разделить команду: да, если это не мешает восстановлению Этот вариант стал самым популярным в Telegram. В нём есть управленческая логика: у нас одновременно инцидент и обязательства перед заказчиком. Но разделить задачи не значит обязательно разделить разработчиков пополам. Пока техническая группа восстанавливает сервис, тимлид или назначенный им человек проверяет готовность демо и связывается с заказчиком. Если для подготовки стенда придётся отвлечь единственного специалиста, способного восстановить прод, — такой параллельный процесс слишком дорог. Особенно если стенд нужно срочно создавать с нуля. 4. Перенести встречу: иногда правильно, но не исчезнуть до выяснения причин Перенос — нормальное решение, если полезный и безопасный показ невозможен. А вот ждать «полной картины», прежде чем написать заказчику, не стоит. Причину могут расследовать долго, но человек уже должен понимать, что происходит с его встречей. А что в итоге делать с заказчиком? Предупредить сразу, а затем прийти с рекомендацией. Первое сообщение не требует готового технического диагноза: У нас возник инцидент в производственной среде. Команда занимается восстановлением, а я проверяю, затрагивает ли он запланированную демонстрацию. Через 10 минут вернусь с предложением по формату встречи. Параллельно выясняем: — работает ли отдельный демостенд и не зависит ли он от проблемной среды; — доступен ли на нём нужный пользовательский сценарий; — есть ли актуальная запись, скриншоты или макеты; — можно ли провести полезную встречу без обращения к нестабильному проду и без отвлечения ключевых специалистов. Дальше — один из трёх сценариев. Если демостенд работает Проверяем запланированный сценарий и проводим встречу, честно обозначив среду: Демонстрационный стенд проверен, инцидент его не затронул. Предлагаем провести встречу на нём по плану. Восстановление производственной среды продолжается. Работающее демо не выдаём за доказательство того, что прод уже восстановлен. Если есть резервные материалы Не устраиваем эксперимент на глазах у заказчика. Предлагаем изменить формат и согласовываем это с ним: Сейчас стабильный живой показ недоступен. Предлагаем показать основной сценарий на записи и обсудить логику решения. Если для вашей задачи важно проверить работу продукта вживую, перенесём демонстрацию. Запись или макеты подходят не для любой встречи. Если цель — приёмка работающей функциональности, они не заменяют её автоматически. Если полноценный показ невозможен Рекомендуем перенос: Инцидент затрагивает запланированную демонстрацию, а равноценного резервного формата сейчас нет. Предлагаем перенести показ, чтобы не тратить ваше время на технические сбои. Через 30 минут сообщим статус и уточним возможность согласовать новую дату. Если готовность к новой дате уже подтверждена, предлагаем два конкретных слота. Если нет — называем время следующего обновления, а не обещаем «завтра в 12:00» без оснований. Обещание вернуться со статусом — не обещание восстановить сервис к этому времени. Чего не стоит делать — Обещать срок восстановления без подтверждённой оценки. — Искать виноватого и пересказывать заказчику внутренний хаос. — Делать вид, что ничего не произошло. — Начинать показ на нестабильном проде в надежде, что «может, не упадёт». — Перекладывать на заказчика выбор из множества технических вариантов. Тимлид приходит не только с проблемой, но и с рекомендацией: «Предлагаем провести встречу на демостенде» или «Рекомендуем перенести демонстрацию». Итоговый план на 40 минут Сразу: организовать работу по инциденту и предупредить заказчика о риске для встречи. В первые 5–10 минут: определить масштаб сбоя, проверить последние изменения, миграции и безопасность отката. Параллельно оценить демостенд и резервные материалы. К контрольной точке через 10 минут: рекомендовать формат встречи или перенос. Если данных недостаточно — сообщить это и назначить следующее обновление. Оставшееся время: команда восстанавливает сервис, ответственный за встречу готовит согласованный сценарий. Если прод восстановили, сначала проверяем его состояние и нужный пользовательский сценарий. Не переключаем демонстрацию на него только потому, что «вроде заработало». Главный вывод Тимлид не выбирает между «чинить прод» и «заниматься заказчиком». Он организует обе задачи, сохраняя приоритет восстановления. Команде нужны согласованные действия. Заказчику — подтверждённые факты, понятная рекомендация и время следующего контакта. Именно в таких ситуациях становится заметно: быть сильным разработчиком и управлять командой — разные задачи. Недостаточно самому знать, как исправить ошибку. Нужно распределить ответственность, выбрать приоритеты и договориться с людьми, когда готового ответа ещё нет. Если вы уже столкнулись с этим переходом или готовитесь стать тимлидом, присмотритесь к нашему курсу для тимлидов. 👉 Программа и подробности — [ссылка на курс].

Причина пока неизвестна. Senior-разработчик, который лучше всех знает систему, будет на связи только через два часа. Команда ждёт вашего решения, а заказчик уже подключается к созвону. Вы — тимлид. Что сделаете первым?

Что делать, если релиз оказался под угрозой, сильный сотрудник потерял мотивацию, продакт спорит с сейлзами, а важную задачу «быстрее сделать самому»? В обычном курсе вам расскажут, как правильно. В симуляторе Тимлида решение придется принимать вам c +110 управленческими сценариями. Вас ждёт один большой сквозной кейс: вы возглавите продуктовую команду и пройдёте вместе с ней весь путь — от найма, онбординга, 1-on-1 и делегирования до работы со стейкхолдерами, конфликтами, метриками, процессами, рисками и релизами.

В демо открыты два полноценных урока: «Ловушки делегирования для тимлида»; «Как растить команду, а не ЧСВ».

Вместе с курсом вы получите бонусный плейлист Podlodka TeamLead и доступ к 70+ инженерными задачами для подготовки к техническим собеседованиям. 93% наших учеников оценили курс на 10 из 10. Но мы всё равно предлагаем не верить нам на слово — сначала пройдите демо. До 15 августа курс можно приобрести со скидкой 30% 45 000 ₽ → 31 500 ₽ Промокод: OTPUSK30 👉 Попробовать бесплатно

Что делать, если релиз оказался под угрозой, сильный сотрудник потерял мотивацию, продакт спорит с сейлзами, а важную задачу «быстрее сделать самому»? В обычном курсе вам расскажут, как правильно. В симуляторе Тимлида решение придется принимать вам c +110 управленческими сценариями. Вас ждёт один большой сквозной кейс: вы возглавите продуктовую команду и пройдёте вместе с ней весь путь — от найма, онбординга, 1-on-1 и делегирования до работы со стейкхолдерами, конфликтами, метриками, процессами, рисками и релизами. В демо открыты два полноценных урока: «Ловушки делегирования для тимлида»; «Как растить команду, а не ЧСВ». Вместе с курсом вы получите бонусный плейлист Podlodka TeamLead и доступ к 70+ инженерными задачами для подготовки к техническим собеседованиям. 93% наших учеников оценили курс на 10 из 10. Но мы всё равно предлагаем не верить нам на слово — сначала пройдите демо. До 15 августа курс можно приобрести со скидкой 30% 45 000 ₽ → 31 500 ₽ Промокод: OTPUSK30

Что делать, если релиз оказался под угрозой, сильный сотрудник потерял мотивацию, продакт спорит с сейлзами, а важную задачу «быстрее сделать самому»? В обычном курсе вам расскажут, как правильно. В симуляторе Тимлида решение придется принимать вам c +110 управленческими сценариями. Вас ждёт один большой сквозной кейс: вы возглавите продуктовую команду и пройдёте вместе с ней весь путь — от найма, онбординга, 1-on-1 и делегирования до работы со стейкхолдерами, конфликтами, метриками, процессами, рисками и релизами. В демо открыты два полноценных урока: «Ловушки делегирования для тимлида»; «Как растить команду, а не ЧСВ». Вместе с курсом вы получите бонусный плейлист Podlodka TeamLead и доступ к 70+ инженерными задачами для подготовки к техническим собеседованиям. 93% наших учеников оценили курс на 10 из 10. Но мы всё равно предлагаем не верить нам на слово — сначала пройдите демо. До 15 августа курс можно приобрести со скидкой 30% 45 000 ₽ → 31 500 ₽ Промокод: OTPUSK30

🔥 Сегодня — самый выгодный день До конца акции осталось 5 дней, и до 15 августа включительно на все курсы Инженерки действует скидка 30% по промокоду OTPUSK30 Но есть важный нюанс: сегодня, 10 августа, последний день, когда эта скидка суммируется с уже действующими скидками на отдельные курсы.

С 11 августа часть цен повысится, а скидки больше не будут складываться. Поэтому если какой-то курс давно лежал в закладках — сегодня действительно хороший момент к нему вернуться.

В карусели показали несколько примеров, а здесь оставим математику 👇 Особенно выгодно сегодня: 🔴 Linux 2 в 1 58 000 ₽ → 40 600 ₽ И сразу два курса по Linux в одном пакете. 🔴Data Warehouse / dbt — пакет из 3 курсов 85 900 ₽ → 60 130 ₽ 🔴Lakehouse на Iceberg + Spark 35 000 ₽ → 24 500 ₽ 🔴Rust 55 000 ₽ → 38 500 ₽ Выгода 16 500 ₽. 🔴Большой курс по DevOps 50 000 ₽ → 35 000 ₽ 🔴Playwright JavaScript / TypeScript или 🔴Playwright Python «Основательный подход»: 45 000 ₽ → 31 500 ₽ «Киберсамурай»: 75 150 ₽ → 52 605 ₽ И да, Инженерка всё ещё про практику, а не бесконечный просмотр лекций. Вы пишете код, поднимаете инфраструктуру, строите DWH и Lakehouse, работаете с Linux на уровне ядра, автоматизируете тестирование и собираете собственные проекты.

Промокод: OTPUSK30

Скидка −30% действует до 15 августа включительно. Но суммировать её с текущими скидками можно только сегодня. Так что сегодня тот редкий случай, когда «потом куплю» действительно может стоить дороже 😁

Когда тревога притворяется управлением рисками - Прод лёг перед релизом. - Ключевой разработчик написал: «Нужно поговорить». - Заказчик второй день не отвечает. - Команда снова не укладывается в оценку спринта. И вот мы уже представляем сорванный запуск, потерянного клиента, развалившуюся команду и неприятный разговор с руководством. Мы и сами такие же. Иногда можем за несколько минут пройти путь от одного непонятного сообщения до мысленного закрытия целого проекта. В такие моменты тревогу легко перепутать с ответственностью. Кажется, что хороший руководитель обязан заранее предусмотреть каждый возможный провал. Но между тревогой и управлением рисками есть важное отличие:

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

Особенно важно помнить об этом сейчас. Рынок меняется, бюджеты пересматриваются, требования бизнеса растут, а решения всё чаще приходится принимать без полной информации и гарантий результата. В такой среде особенно ценятся руководители, которые не замирают перед неопределённостью, а умеют: - брать ответственность за решения; - быстро адаптироваться к новым условиям; - отделять реальные риски от предположений; - сохранять фокус команды; - действовать даже тогда, когда идеального плана ещё нет. Руководителю не всегда нужно сразу понимать, как спасти весь проект. Для начала достаточно определить ближайшую точку принятия решения: - что мы уже знаем о проблеме; - каких данных нам не хватает; - какое решение нельзя откладывать; - кто отвечает за следующий шаг; - когда мы снова оцениваем ситуацию. Если релиз задерживается, не нужно сразу решать судьбу продукта на год вперёд. Сначала стоит разобраться в причинах задержки, критичности блокеров и реальной дате готовности. Если специалист хочет поговорить, не нужно заранее искать ему замену. Сначала нужно провести разговор. Если заказчик недоволен, не нужно мысленно закрывать контракт. Нужно понять, где именно разошлись ожидания и что ещё можно исправить. Одно из главных правил руководителя в IT:

не пытаться контролировать все возможные сценарии, а создавать ясность там, где её можно создать прямо сейчас

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

Сейчас на наши программы для C-level и IT-руководителей действует скидка 30% по промокоду OTPUSK30.

Среди них — программы для тимлидов, руководителей команд и технических директоров. Они помогут системнее работать с людьми, процессами, рисками и сложными управленческими решениями в условиях неопределённости.

В IT иногда достаточно одного тревожного сигнала, чтобы мысленно похоронить весь проект. Прод лёг перед релизом. Ключевой разработчик написал: «Нужно поговорить». Заказчик второй день не отвечает. Команда снова не укладывается в оценку спринта. И вот мы уже представляем сорванный запуск, потерянного клиента, развалившуюся команду и неприятный разговор с руководством. Мы и сами такие же. Иногда можем за несколько минут пройти путь от одного непонятного сообщения до мысленного закрытия целого проекта. В такие моменты тревогу легко перепутать с ответственностью. Кажется, что хороший руководитель обязан заранее предусмотреть каждый возможный провал. Но между тревогой и управлением рисками есть важное отличие: управление рисками приводит к плану действий, а тревога — только к новым сценариям катастрофы. Особенно важно помнить об этом сейчас. Рынок меняется, бюджеты пересматриваются, требования бизнеса растут, а решения всё чаще приходится принимать без полной информации и гарантий результата. В такой среде особенно ценятся руководители, которые не замирают перед неопределённостью, а умеют: — брать ответственность за решения; — быстро адаптироваться к новым условиям; — отделять реальные риски от предположений; — сохранять фокус команды; — действовать даже тогда, когда идеального плана ещё нет. Руководителю не всегда нужно сразу понимать, как спасти весь проект. Для начала достаточно определить ближайшую точку принятия решения: — что мы уже знаем о проблеме; — каких данных нам не хватает; — какое решение нельзя откладывать; — кто отвечает за следующий шаг; — когда мы снова оцениваем ситуацию. Если релиз задерживается, не нужно сразу решать судьбу продукта на год вперёд. Сначала стоит разобраться в причинах задержки, критичности блокеров и реальной дате готовности. Если специалист хочет поговорить, не нужно заранее искать ему замену. Сначала нужно провести разговор. Если заказчик недоволен, не нужно мысленно закрывать контракт. Нужно понять, где именно разошлись ожидания и что ещё можно исправить. Одно из главных правил руководителя в IT: не пытаться контролировать все возможные сценарии, а создавать ясность там, где её можно создать прямо сейчас. Сильный менеджмент сегодня — это не отсутствие сомнений и не способность предсказать будущее. Это умение принимать решения, перестраиваться и вести команду вперёд, даже когда правила меняются по ходу игры. Сейчас на наши программы для C-level и IT-руководителей действует скидка 30% по промокоду OTPUSK30. Среди них — программы для тимлидов, руководителей команд и технических директоров. Они помогут системнее работать с людьми, процессами, рисками и сложными управленческими решениями в условиях неопределённости.

🔥 У Инженерки небольшие каникулы, а у вас — скидка 30% Ребята, в августе наша команда ненадолго уходит в отпуск. А чтобы курсы не скучали без нас, зазывать вас на обучение временно будет тот самый надувной чел 😁 Поддержка по всем вопросам, связанным с обучением, продолжит работать в будние дни. А пока мы на перезагрузке до 15 августа включительно на все курсы Инженерки действует скидка 30% Также до 15 августа обучение ещё можно оформить в рамках нашей образовательной лицензии. После этой даты мы начнем переход на новый юридический статус, поэтому такая возможность временно станет недоступна. У нас также действует иностранная оплата: вы всегда можете перейти на иностранную версию сайта и оплатить любой интересующий вас курс. Так что самое время открыть вкладку, в которой уже давно лежит выбранный курс, и наконец добраться до него. Торопиться с прохождением не придётся — доступ останется с вами бессрочно.

Промокод: OTPUSK30 Скидка 30% до 15 августа включительно.