Коллега, метафора красивая, но вы перепутали Input (питание) и Workload (нагрузку).
Лошадь в вашей истории сдохла от отсутствия энергии. А в моем случае «лошадь» (я) раньше дохла от того, что на ней одновременно пытались ехать: заказчик, три менеджера, соседний отдел и еще кто-то просил «подержать пианино».
Режим Default Deny — это не голодовка. Это защита от перегрузки. Я не перестал есть сено (делать задачи), я перестал жрать пластик и картон, который мне подсовывали под видом еды (пустые митинги и чужая работа).
Но технически вы правы: если навсегда заблокировать 100% портов, сервер станет бесполезным кирпичом и его выкинут из дата-центра. Поэтому после этапа «карантина» необходимо настроить Allowlist (белый список). Пропускать только полезный трафик, а спам — в /dev/null.
Так что лошадь жива, здорова))) и наконец-то везет только своего всадника, а не весь табор.
Так, стоп. Я тут посмотрел свои логи и понял одну вещь. То, что я называю ленью или прокрастинацией — это вообще не оно. Это, блин, аварийный протокол безопасности.
Смотри, что происходит. У меня в базе данных записан негативный опыт: "Помнишь, как в прошлый раз мы пытались задеплоить сложную фичу за 15 минут до обеда? Мы тогда чуть не спалили материнку, вспотели, перенервничали, а на выходе получили говнокод".
Система этот инцидент запомнила и повесила на любую сложную задачу красный флаг: [CRITICAL ERROR RISK].
И теперь, даже когда у меня есть нормальный слот времени (ресурсный отрезок), мой внутренний "Администратор" блокирует доступ к кнопке "Пуск". Он рассуждает логично: "Братан, я не дам тебе запустить этот процесс. В прошлый раз ты перегрелся. Сейчас ты опять начнешь перфекционистски вылизывать код, времени не хватит, ты расстроишься и упадешь в синий экран. Ну нафиг. Лучше посидим в простое (Idle), целее будем".
Получается, я не ленивый. Я просто запуганный собственным перфекционизмом. Я боюсь не самой работы, я боюсь того чувства, когда "сделал плохо, потому что не успел".
Как это хакнуть? Надо снизить "Уровень Сервиса" (SLA) для самого себя. Договориться с внутренним админом: "Слушай, мы не будем сейчас писать идеальный код для продакшена. Мы просто набросаем MVP из палок и изоленты. Грязный черновик. Чисто потестить".
На "черновик" система ресурсов не жалеет. А там, глядишь, и втянемся)))
Конечно можно. В ChatGPT получаю „среднее по больнице“, а у терапевта — счет за 50 часов работы, чтобы понять, что мама меня недолюбила :) шучу.. Если у вас аптайм 100% на советах GPT — искренне жму руку, у меня так не скомпилировалось.
Хах, в точку! Если Лид — это защищенный бэкенд, который сидит за NAT-ом и держит прод, то Менеджер — это API Gateway (или Reverse Proxy) на самой передовой под обстрелом.
Если Гейтвей начнет всем подряд отдавать 403 Forbidden, клиентская система просто „отвалится“ с ошибкой, и заменят на более „стабильный модуль“. Как вариант, тут нужен не жесткий Фаервол, а Traffic Shaping и Rate Limiting:
Не „Идите лесом“, а 202 Accepted («Ваш запрос принят в очередь, расчетное время обработки — Q3»).
Не „Нет“, а 429 Too Many Requests («Снизьте нагрузку, или система ляжет, и вы не получите вообще ничего»).
Или классический трейд-офф: „Ок, мы пропускаем этот пакет срочно, но тогда система автоматически дропает пакет «Релиз в пятницу». Подтверждаете транзакцию?“
Это уже высший пилотаж — когда клиент слышит «Да», но по факту встает в ту очередь, в которую нужно вам))
Мы просто путаем мозг с жестким диском. А он — процессор. Ему нужно думать, а не хранить файлы.
Как только выгружаешь задачи на бумагу или в приложение — сразу чувствуешь, как „оперативка“ освобождается. Внутренний вентилятор перестает шуметь, и голова остывает.
Согласен на 100%. Бег или ходьба — это часто просто разгон кулера, пока фоновые процессы продолжают жрать память.
А вот игровые виды спорта — это уже чистое аппаратное прерывание. Мозгу приходится перебрасывать весь ресурс на обработку физики мяча и координацию, и на «подумать о баге» RAM уже тупо не хватает.
Про думскроллинг как защитный механизм — вообще жиза. По сути, это мы сами себя DDoS-им мусорным трафиком, чтобы заглушить тревожные процессы. Метод рабочий, но сервер греется :)
Рад, что отозвалось. На самом деле, чем больше копаюсь, тем страшнее: там внутри сплошное легаси времен палеолита, документации нет, а разработчик давно уволился. Вот и приходится писать свои патчи поверх этого спагетти-кода, чтобы система не падала каждый понедельник))
Ну в системной инженерии чудес не бывает. Принцип GIGO (Garbage In — Garbage Out) работает и для моей биологической нейросети. Если на входе null, на выходе тоже будет null.
Я в таких случаях запускаю диагностику по двум веткам:
1. Ошибка Empty Dataset (База пуста) Если идей нет вообще — значит, я пытаюсь сделать SELECT к пустой таблице. Я просто не обучил свою нейронку на текущем контексте. Мой алгоритм: Выключаю режим «Генератор» и включаю режим ETL (Extract, Transform, Load). Иду «пылесосить» данные: документацию смежных технологий, кейсы из вообще других индустрий, решения конкурентов. Просто загружаю в голову сырые данные, даю им ночь на индексацию, и на утро (как правило) запрос выполняется сам собой.
2. Ошибка Processing Error (Данные есть, но не стыкуются) Если каша в голове есть, а решения нет — это фрагментация. Тут мне помогает только классика — Rubber Duck Debugging (Метод утенка). Беру утку (кота / фикус). Сажаю напротив. И начинаю вслух, построчно объяснять: „Смотри, утка. Цель такая. Я пробовал Х, не вышло, потому что Y...“.
В процессе сериализации (перевода мыслей в речь) мозг сам находит битые ссылки. Обычно инсайт прилетает достаточно быстро, а утка даже крякнуть не успевает.
Короче: я либо кормлю базу, либо дефрагментирую кэш об "утку". Как-то так))
О, спасибо за наводку на Линдермана! Это прямо подарок. Всегда приятно, когда интуитивную „инженерную гигиену“ можно подпереть строгой математикой. Получается, если наложить его переменные на мою архитектуру, получается попадание:
Снижение $\lambda$ (отвлечения) — это как раз то, зачем я так топлю за «Фаервол» и режим Default Deny. Если не резать входящие на уровне порта, уравнение просто не сойдется — день превратится в решето.
Уменьшение $\Delta$ (время возврата) — вот здесь и работает «RAM Dump». По сути, это быстрая сериализация контекста на бумагу. Когда у тебя есть сохраненный лог, время „холодной загрузки“ обратно в задачу сокращается с 20 минут до пары секунд.
Параметр $\theta$ (минимальный блок) — железный аргумент в пользу того, почему большие задачи надо декомпозировать под реальные слоты (спринты), а не ждать мифического „свободного дня“, которого никогда не будет.
Крутая модель, обязательно изучу детальнее. Спасибо!
Коллега, метафора красивая, но вы перепутали Input (питание) и Workload (нагрузку).
Лошадь в вашей истории сдохла от отсутствия энергии. А в моем случае «лошадь» (я) раньше дохла от того, что на ней одновременно пытались ехать: заказчик, три менеджера, соседний отдел и еще кто-то просил «подержать пианино».
Режим
Default Deny— это не голодовка. Это защита от перегрузки. Я не перестал есть сено (делать задачи), я перестал жрать пластик и картон, который мне подсовывали под видом еды (пустые митинги и чужая работа).Но технически вы правы: если навсегда заблокировать 100% портов, сервер станет бесполезным кирпичом и его выкинут из дата-центра. Поэтому после этапа «карантина» необходимо настроить Allowlist (белый список). Пропускать только полезный трафик, а спам — в
/dev/null.Так что лошадь жива, здорова))) и наконец-то везет только своего всадника, а не весь табор.
Так, стоп. Я тут посмотрел свои логи и понял одну вещь. То, что я называю ленью или прокрастинацией — это вообще не оно. Это, блин, аварийный протокол безопасности.
Смотри, что происходит. У меня в базе данных записан негативный опыт: "Помнишь, как в прошлый раз мы пытались задеплоить сложную фичу за 15 минут до обеда? Мы тогда чуть не спалили материнку, вспотели, перенервничали, а на выходе получили говнокод".
Система этот инцидент запомнила и повесила на любую сложную задачу красный флаг: [CRITICAL ERROR RISK].
И теперь, даже когда у меня есть нормальный слот времени (ресурсный отрезок), мой внутренний "Администратор" блокирует доступ к кнопке "Пуск". Он рассуждает логично: "Братан, я не дам тебе запустить этот процесс. В прошлый раз ты перегрелся. Сейчас ты опять начнешь перфекционистски вылизывать код, времени не хватит, ты расстроишься и упадешь в синий экран. Ну нафиг. Лучше посидим в простое (Idle), целее будем".
Получается, я не ленивый. Я просто запуганный собственным перфекционизмом. Я боюсь не самой работы, я боюсь того чувства, когда "сделал плохо, потому что не успел".
Как это хакнуть? Надо снизить "Уровень Сервиса" (SLA) для самого себя. Договориться с внутренним админом: "Слушай, мы не будем сейчас писать идеальный код для продакшена. Мы просто набросаем MVP из палок и изоленты. Грязный черновик. Чисто потестить".
На "черновик" система ресурсов не жалеет. А там, глядишь, и втянемся)))
Конечно можно. В ChatGPT получаю „среднее по больнице“, а у терапевта — счет за 50 часов работы, чтобы понять, что мама меня недолюбила :) шучу.. Если у вас аптайм 100% на советах GPT — искренне жму руку, у меня так не скомпилировалось.
Забирайте в свой репозиторий) Рад, что зашло. Удачного деплоя!
Хах, в точку! Если Лид — это защищенный бэкенд, который сидит за NAT-ом и держит прод, то Менеджер — это API Gateway (или Reverse Proxy) на самой передовой под обстрелом.
Если Гейтвей начнет всем подряд отдавать
403 Forbidden, клиентская система просто „отвалится“ с ошибкой, и заменят на более „стабильный модуль“. Как вариант, тут нужен не жесткий Фаервол, а Traffic Shaping и Rate Limiting:Не „Идите лесом“, а
202 Accepted(«Ваш запрос принят в очередь, расчетное время обработки — Q3»).Не „Нет“, а
429 Too Many Requests(«Снизьте нагрузку, или система ляжет, и вы не получите вообще ничего»).Или классический трейд-офф: „Ок, мы пропускаем этот пакет срочно, но тогда система автоматически дропает пакет «Релиз в пятницу». Подтверждаете транзакцию?“
Это уже высший пилотаж — когда клиент слышит «Да», но по факту встает в ту очередь, в которую нужно вам))
Мы просто путаем мозг с жестким диском. А он — процессор. Ему нужно думать, а не хранить файлы.
Как только выгружаешь задачи на бумагу или в приложение — сразу чувствуешь, как „оперативка“ освобождается. Внутренний вентилятор перестает шуметь, и голова остывает.
Правда,: к этой тишине привыкаешь мгновенно))
Согласен на 100%. Бег или ходьба — это часто просто разгон кулера, пока фоновые процессы продолжают жрать память.
А вот игровые виды спорта — это уже чистое аппаратное прерывание. Мозгу приходится перебрасывать весь ресурс на обработку физики мяча и координацию, и на «подумать о баге» RAM уже тупо не хватает.
Про думскроллинг как защитный механизм — вообще жиза. По сути, это мы сами себя DDoS-им мусорным трафиком, чтобы заглушить тревожные процессы. Метод рабочий, но сервер греется :)
Рад, что отозвалось. На самом деле, чем больше копаюсь, тем страшнее: там внутри сплошное легаси времен палеолита, документации нет, а разработчик давно уволился. Вот и приходится писать свои патчи поверх этого спагетти-кода, чтобы система не падала каждый понедельник))
Ну в системной инженерии чудес не бывает. Принцип GIGO (Garbage In — Garbage Out) работает и для моей биологической нейросети. Если на входе
null, на выходе тоже будетnull.Я в таких случаях запускаю диагностику по двум веткам:
1. Ошибка
Empty Dataset(База пуста) Если идей нет вообще — значит, я пытаюсь сделатьSELECTк пустой таблице. Я просто не обучил свою нейронку на текущем контексте. Мой алгоритм: Выключаю режим «Генератор» и включаю режим ETL (Extract, Transform, Load). Иду «пылесосить» данные: документацию смежных технологий, кейсы из вообще других индустрий, решения конкурентов. Просто загружаю в голову сырые данные, даю им ночь на индексацию, и на утро (как правило) запрос выполняется сам собой.2. Ошибка
Processing Error(Данные есть, но не стыкуются) Если каша в голове есть, а решения нет — это фрагментация. Тут мне помогает только классика — Rubber Duck Debugging (Метод утенка). Беру утку (кота / фикус). Сажаю напротив. И начинаю вслух, построчно объяснять: „Смотри, утка. Цель такая. Я пробовал Х, не вышло, потому что Y...“.В процессе сериализации (перевода мыслей в речь) мозг сам находит битые ссылки. Обычно инсайт прилетает достаточно быстро, а утка даже крякнуть не успевает.
Короче: я либо кормлю базу, либо дефрагментирую кэш об "утку". Как-то так))
О, спасибо за наводку на Линдермана! Это прямо подарок. Всегда приятно, когда интуитивную „инженерную гигиену“ можно подпереть строгой математикой. Получается, если наложить его переменные на мою архитектуру, получается попадание:
Снижение $\lambda$ (отвлечения) — это как раз то, зачем я так топлю за «Фаервол» и режим
Default Deny. Если не резать входящие на уровне порта, уравнение просто не сойдется — день превратится в решето.Уменьшение $\Delta$ (время возврата) — вот здесь и работает «RAM Dump». По сути, это быстрая сериализация контекста на бумагу. Когда у тебя есть сохраненный лог, время „холодной загрузки“ обратно в задачу сокращается с 20 минут до пары секунд.
Параметр $\theta$ (минимальный блок) — железный аргумент в пользу того, почему большие задачи надо декомпозировать под реальные слоты (спринты), а не ждать мифического „свободного дня“, которого никогда не будет.
Крутая модель, обязательно изучу детальнее. Спасибо!