24.09.2025 06:51
AdminFuture 130 23000 Источник
Ржавчина
Ржавчина

Введение: Невидимая ржавчина IT-инфраструктуры

Привет, коллеги! Хочу рассказать одну историю. Был у нас в стойке один сервер. Назовем его «Феникс». Работал как часы, аптайм — 986 дней. Мы им гордились, ставили в пример новичкам, мол, вот как надо настраивать железо и софт. А потом пришло время планового техобслуживания в дата-центре. Простое выключение-включение. «Феникс» больше не взлетел. RAID-контроллер решил, что с него хватит, а заодно прихватил с собой пару дисков из массива. Вот тогда я впервые по-настояшему задумался о том, что цифровой мир подчиняется тем же жестоким законам, что и физический.

В теории, код и данные — это нечто вечное. Биты не ржавеют, скрипты не изнашиваются. Но на практике любая сложная система со временем деградирует. Это не просто отказ железа ; это медленный, неумолимый «постепенный скат в беспорядок» , который затрагивает всё: софт, конфигурации, данные. Это явление, которое я для себя называю  цифровой энтропией, — наш с вами постоянный и невидимый враг. Наша работа — не просто строить системы, а вести непрерывную войну с их неизбежным распадом.  

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

Глава 1: Ужасы долгого аптайма, или почему «пять девяток» не всегда хорошо

Когда-то давно я, как и многие, восхищался серверами с аптаймом в год и больше. 1000+ дней! Казалось, это эталон стабильности. Каким же я был наивным. Сегодня, когда я вижу сервер, не перезагружавшийся сотни дней, я испытываю не гордость, а тихий ужас. Такой сервер — не образец стабильности, а тикающая бомба. Система, которая годами не проверяла собственные процедуры запуска.  

Байки из склепа (истории сисадминов)

Байки из склепа
Байки из склепа

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

  • Один коллега рассказал, как планово перезагружал vSphere-хост с аптаймом 300+ дней. После ребута система не нашла загрузочный USB-диск — он оказался поврежден. Гипервизор для клиента просто перестал существовать.  

  • Другой админ с ужасом смотрел на SAN-хранилище с аптаймом в 1400 дней. Никто не решался его трогать, потому что все понимали: при перезагрузке есть неиллюзорный шанс столкнуться с массовым отказом старых дисков.  

  • Классика жанра: сервер выключают для замены одного сбойного диска в RAID-массиве (не hotswap). После включения умирает еще один диск.  

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

  • Или вот еще, про программный распад: админ унаследовал несколько Debian-серверов с аптаймом 1300+ дней. Когда он попытался запустить apt-get update, выяснилось, что репозитории для этой версии ОС уже давно не существуют.  

Техническое «почему?»

Этот страх перед перезагрузкой имеет под собой абсолютно рациональные причины.

  • Скрытые повреждения: Файлы и участки кода, которые используются только при загрузке системы, могут быть давно повреждены. Работающая система этого не заметит. Ошибка вылезет только в самый неподходящий момент — при ребуте. Перспектива запустить fsck на файловой системе, которую не проверяли 2666 дней, способна вызвать седину.  

  • Физическая деградация: Железо стареет. Жесткие диски — это механика. Смазка в подшипниках густеет, головки изнашиваются. Электролитические конденсаторы на материнской плате и в блоках питания высыхают. Пыль, забившаяся в радиаторы, приводит к постоянному перегреву, что ускоряет деградацию компонентов. Перезагрузка — это момент пикового стресса для старого оборудования.  

  • Слепые зоны безопасности: Сервер, который не перезагружался годами, почти наверняка уязвим, так как на нем не установлены критические обновления ядра, требующие перезагрузки. Технологии live patching помогают, но они не всесильны. Кроме того, перезагрузка — это эффективный способ прервать работу вредоносного ПО, закрепившегося только в оперативной памяти.  

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

Глава 2: Призраки в машине: конкретные проявления энтропии

Призрак в машине
Призрак в машине

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

2.1. Призрак-обжора: Утечки памяти

Это медленный и коварный процесс, когда приложение захватывает память, но «забывает» ее освободить после использования. Со временем это приводит к деградации производительности, чрезмерному использованию swap и, в конечном итоге, к падению приложения или всей системы. Это классический пример роста энтропии внутри запущенного процесса.  

Причины и обнаружение: Чаще всего виноваты незакрытые ресурсы, бесконтрольно растущие структуры данных или ошибки в сторонних библиотеках. Заметить призрака-обжору можно с помощью простых утилит вроде top, htop или даже «Диспетчера задач» в Windows, наблюдая за колонкой потребления памяти (RES или Working Set). Если она неуклонно растет со временем — у вас проблема.  

Галерея негодяев:

  • Apache/PHP: Классическая связка, склонная к утечкам. Верный признак — когда команда /etc/init.d/httpd reload временно снижает потребление памяти, что подтверждает источник проблемы. Инструменты вроде Phusion Passenger могут помочь, автоматически перезапуская «зажравшиеся» рабочие процессы. Иногда утечки могут быть и вовсе экзотическими, как в случае с уязвимостью Optionsbleed, когда фрагменты памяти сервера могли утекать наружу в HTTP-ответах.  

  • Nginx: Хотя Nginx славится своей стабильностью, он тоже не застрахован от проблем, особенно при использовании сторонних модулей или в специфических сценариях, например, с долгоживущими gRPC-стримами. Интересно, чтоnginx -s reload иногда может усугубить утечку по сравнению с полным перезапуском сервиса.  

  • PostgreSQL: У Postgres есть своя продвинутая система управления памятью, основанная на «контекстах» (MemoryContexts), которая спроектирована так, чтобы предотвращать утечки между запросами. Однако утечка все еще может произойти внутри одного долгоживущего соединения. На общее потребление памяти сильно влияют такие параметры, как shared_buffers и work_mem.  

Практический совет: Видите, что процесс httpd или postgres со временем отъедает всё больше памяти? Не спешите грешить на ядро. Просто перезапустите сервис в окно обслуживания и посмотрите, вернется ли память. Если да — поздравляю, у вас живёт призрак-обжора.

2.2. Призрак-бродяга: Зомби-процессы

Говоря простым языком, зомби — это дочерний процесс, который уже завершил свою работу, но запись о нем все еще висит в таблице процессов, потому что родительский процесс не удосужился прочитать его код завершения (не вызвал системную функцию wait()).  

Почему они важны (и не очень): Один-два зомби абсолютно безвредны. Они не потребляют ни процессорного времени, ни оперативной памяти. Опасность возникает, когда их становится много. Накопление зомби-процессов может исчерпать лимит идентификаторов процессов (PID) в системе, что сделает невозможным запуск новых процессов и приведет к дестабилизации всей ОС.  

Охота и экзорцизм: Найти этих бродяг можно простой командой: ps aux | awk '$8=="Z"' (вариация на тему команд из ).  

Попытка убить зомби командой kill -9 бессмысленна — он и так уже мертв. Решение — разобраться с его родителем. Сначала находим PID родителя:  

ps -o ppid= <PID_ЗОМБИ>

А затем либо мягко намекаем ему, что пора бы прибраться за своими детьми, послав сигнал SIGCHLD, либо, если это не помогает, жестко убиваем самого родителя.  

2.3. Призрак с плохой памятью: Протухший кэш DNS

Классическая проблема: «Сайт лежит!» — кричит пользователь. «У меня все работает!» — отвечает админ. Знакомая ситуация, когда после смены DNS-записей один конкретный сервер или пользователь продолжает видеть старый IP-адрес. Это энтропия в распределенных системах данных.  

Круги кэширования:

  1. Кэш браузера: Первый уровень. Тот же Google Chrome имеет свой собственный внутренний DNS-кэш.  

  2. Кэш ОС: Windows, macOS и Linux кэшируют DNS-запросы на уровне операционной системы. И здесь долгий аптайм снова выходит боком — кэш мог не сбрасываться месяцами.  

  3. Локальный DNS-демон (Linux): В современных дистрибутивах Linux за кэширование чаще всего отвечает systemd-resolved. Но в старых системах можно встретить печально известный nscd. Его проблема в том, что он нестабилен, может не уважать TTL записей и является внутренней частью glibc, из-за чего утилиты вроде dig или nslookup его игнорируют, обращаясь к DNS-серверам напрямую, что сбивает с толку при диагностике.  

  4. Кэш роутера/провайдера/публичного DNS: Последний рубеж, который часто находится вне нашего контроля. Здесь ключевую роль играет TTL (Time-To-Live) — время жизни записи в кэше. Слишком высокий TTL может привести к тому, что изменения будут «распространяться» по миру очень долго.  

Чтобы не держать в голове все команды, вот небольшая шпаргалка.

Таблица 1: Шпаргалка по очистке DNS-кэша

Платформа/ПО

Команда

Примечания

Windows (CMD)

ipconfig /flushdns

Запускать от имени администратора.  

Windows (PowerShell)

Clear-DnsClientCache

Запускать от имени администратора.  

macOS (актуальные)

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Команда может меняться в зависимости от версии ОС.  

Linux (systemd-resolved)

sudo resolvectl flush-caches

В старых версиях может быть systemd-resolve --flush-caches.  

Linux (nscd)

sudo /etc/init.d/nscd restart

Перезапуск демона очищает его кэши.  

Google Chrome

chrome://net-internals/#dns (в адресной строке)

Нажать кнопку "Clear host cache".  

2.4. Призрак-Плюшкин: Разросшиеся логи

Логи — это жизненно важный инструмент для диагностики, но в то же время это форма информационной энтропии. Оставленные без присмотра, они будут расти бесконечно, пока не съедят все свободное место на диске, что приведет к отказу сервисов.  

Укротитель хаоса: logrotate На Linux-системах для борьбы с этим явлением есть стандартный и проверенный временем инструмент — logrotate. Его задача проста: по расписанию или при достижении определенного размера архивировать (сжимать), переименовывать и удалять старые лог-файлы.  

Конфигурация обычно состоит из главного файла /etc/logrotate.conf с настройками по умолчанию и отдельных файлов для конкретных приложений в директории /etc/logrotate.d/.  

Таблица 2: Ключевые директивы logrotate

Директива

Пример

Объяснение

daily/weekly/monthly

weekly

Частота ротации: ежедневно, еженедельно, ежемесячно.  

rotate

rotate 14

Сколько старых лог-файлов хранить (в данном случае — 14).  

compress

compress

Сжимать старые лог-файлы (по умолчанию используется gzip).  

delaycompress

delaycompress

Сжимать лог-файл при следующей ротации. Полезно, если программа не может сразу отпустить файловый дескриптор.  

missingok

missingok

Не выдавать ошибку, если лог-файл отсутствует.  

notifempty

notifempty

Не ротировать пустой лог-файл.  

size

size 100M

Ротировать файл, когда он достигнет указанного размера (например, 100 МБ).  

sharedscripts

sharedscripts

Выполнять postrotate скрипт один раз для всех логов в блоке, а не для каждого по отдельности.  

postrotate...endscript

postrotate /usr/sbin/apachectl graceful endscript

Команды, которые нужно выполнить после ротации. Обычно это перезапуск или reload сервиса.  

Важно понимать, что все эти «призраки» взаимосвязаны. Долгий аптайм усугубляет утечки памяти и старение DNS-кэша. Неконтролируемые логи могут привести к падению сервиса, который, в свою очередь, не сможет нормально перезапуститься из-за скрытой ошибки загрузки, создавая каскадный сбой. Это и есть цифровая энтропия в действии.

Глава 3: Экзорцизм для админа: наш арсенал против хаоса

Экзорцизм
Экзорцизм

Мы познакомились с монстрами. Теперь поговорим о том, как с ними бороться. Ключевой момент — переход от реактивного «тушения пожаров» к продуманной стратегии управления энтропией.

3.1. Священный ритуал перезагрузки

Плановые, регулярные перезагрузки — это не признак нестабильности системы (как во времена Windows 9x), а важнейшая проверка ее здоровья. Это единственный надежный способ протестировать скрипты автозапуска, выявить скрытые проблемы с железом и применить обновления ядра. Запомните простое правило:  

если вы боитесь перезагружать сервер, значит, вы УЖЕ потеряли над ним контроль.

3.2. Неусыпный дозор: Мониторинг и автоматизация

Настройте мониторинг ключевых метрик: загрузка ЦП, использование ОЗУ и диска, количество зомби-процессов. Создайте простые скрипты для ежедневной проверки состояния системы, которые будут присылать вам короткий отчет. Автоматизация — наше главное оружие для обнаружения энтропии до того, как она вызовет сбой.  

3.3. Парадигма Феникса: Неизменяемая (Immutable) инфраструктура

Это самый мощный и современный метод борьбы с энтропией. Он основан на смене самой философии управления серверами.

От питомцев к стаду: Старый подход — это «серверы-питомцы» (pets). Мы даем им имена (как моему «Фениксу»), заботимся о них, лечим, когда они болеют. Новый подход — «серверы-стадо» (cattle). Они безлики, идентичны, и когда один из них «заболевает», мы его не лечим, а просто заменяем новым.  

Золотой образ: В основе этого подхода лежит «золотой образ» (golden image). Это эталонный, предварительно настроенный шаблон виртуальной машины. Он содержит в себе операционную систему, все необходимые агенты (мониторинга, безопасности), код приложения и скрипты для усиления безопасности. Это единственный источник правды.  

Рабочий процесс:

  1. Сборка: Вместо того чтобы настраивать сервер после запуска, вы «запекаете» все необходимое в новую версию золотого образа с помощью таких инструментов, как Packer.  

  2. Развертывание: Вы разворачиваете новые экземпляры серверов из этого образа, используя инструменты «инфраструктура как код» (IaC), например, Terraform.  

  3. Обновление/Патчинг: Нужно установить патч безопасности или обновить приложение? Вы не заходите на работающий сервер по SSH. Вы собираете новый золотой образ с обновлениями, а затем уничтожаете старые серверы и заменяете их новыми, созданными из свежего образа.  

Этот подход полностью уничтожает «дрейф конфигурации» и накопление системного мусора. Он является логическим завершением всей нашей борьбы с энтропией. Проблема долгого аптайма исчезает, потому что серверы регулярно заменяются. Утечки памяти сбрасываются при каждой замене. Ошибки конфигурации и программный распад становятся невозможными, потому что каждый сервер — идеальная копия протестированного эталона.

Заключение: Принять хаос и научиться им управлять

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

Энтропия — это фундаментальная константа нашего мира, и цифровой мир — не исключение. Наша задача — не победить ее, это невозможно. Наша задача — управлять ею. Современный системный администратор или DevOps-инженер — это архитектор отказоустойчивых систем, который проектирует процессы (такие как неизменяемая инфраструктура), принимающие эфемерную природу серверов, а не сражающиеся с ней.

В следующий раз, когда вы увидите сервер с аптаймом в 1000 дней, не гордитесь им. Пожалейте его. И запланируйте ему достойные проводы, заменив его молодым и свежим клоном. В этом и есть дзен современного администрирования: не привязываться к железу и софту, а выстраивать процессы, которые переживут любую отдельную железку.

Комментарии (130)


  1. maksimshap
    24.09.2025 07:06
    #28874964

    Всколыхнуло воспоминания о нашем «старичке» — файл-сервере под FreeBSD, который молотил без перезагрузки больше четырех лет. Мы на него буквально дышать боялись. Когда пришло время его списывать, решили ради спортивного интереса все-таки ребутнуть. И ведь поднялся, зараза! Но ровно до того момента, как мы попытались скопировать с него данные. Сетевая карта отвалилась намертво — ядро после перезагрузки просто не нашло драйвер, который не обновлялся со времен динозавров. Вот тогда и начались классические «танцы с бубном».


    1. vis_inet
      24.09.2025 07:06
      #28878486

      ядро после перезагрузки просто не нашло драйвер, который не обновлялся со времен динозавров

      Может я глупость спрошу...

      А куда делася старый драйвер?

      Почему ядро решило искать новый?


      1. mayorovp
        24.09.2025 07:06
        #28878786

        Предположу что кто-то в прошлом удалил его командой rm. Возможно, он собирался положить на его место новую версию драйвера, но не нашёл её. Или кто-то отвлёк.


        1. vis_inet
          24.09.2025 07:06
          #28878796

          Т.е. вопрос к качеству обслуживания/сопровождения.


        1. JBFW
          24.09.2025 07:06
          #28879742

          А я предположу, что в потрошка FreeBSD полез молодой, бывший виндовый админ, ужаснулся, что сервер не перезагружали больше недели и "не обновляли систему", немедленно всё обновил и отправил в ребут.

          И тут-то что-то пошло не так...


          1. mayorovp
            24.09.2025 07:06
            #28879888

            Во-первых, ваше предположение противоречит описанию ситуации:

            Когда пришло время его списывать, решили ради спортивного интереса все-таки ребутнуть.

            Во-вторых, не должен исчезать драйвер сетевой карты при штатном обновлении системы.


            1. JBFW
              24.09.2025 07:06
              #28880456

              Допустим, вы обновили ядро ОС.
              Во Фре это сделать было чуть-чуть сложнее, его еще пересобрать надо, а в Линуксе сейчас вот вообще просто в порядке апдейта, особенно если настроить автообновление.

              Но в новой версии ядра что-то поломали - такое было раньше, и бывает сейчас. И теперь при загрузке сетевая карта не определилась, или определилась не так, и драйвер не заработал.
              Вот и "не должен".

              Во Фре драйвера вкомпилены в ядро (раньше так было во всяком случае), при обновлении дерева исходников ядра старый драйвер мог некорректно заработать с новым ядром (такое встречалось, правда, там был драйвер несовсем стандартной железки, но теоретически мог быть и драйвер сетевой).

              Из относительно свежих примеров - отказы в работе c WiFi-чипами в Убунте, пропадание поддержки звука через HDMI, пропадание сетевой карты в Армбиане.

              И вот это всё вы увидите только после перезагрузки на новом ядре. после штатного в общем-то процесса обновления.


              1. mayorovp
                24.09.2025 07:06
                #28880694

                То есть, кто-то в прошлом обновил систему, но не стал перезагружать, а потому перезагрузка через пару лет не удалась? Да, звучит правдоподобно.


          1. Ogoun
            24.09.2025 07:06
            #28880750

            В моей практике были windows-2000 сервера которые не перезагружались годами. От системы не зависит и у каждой системы есть свои проблемы.


          1. SystemOutPrintln
            24.09.2025 07:06
            #28882418

            сервер не перезагружали больше недели и "не обновляли систему", немедленно всё обновил и отправил в ребут

            Любой нормальный сервер должен переживать подобные манипуляции без сбоев.

            Если сервер от них сломался, то это значит, что с машиной явно что-то совсем не так. И не важно, виндовый админ с ним поработал или нет...

            и "не обновляли систему"

            Ну так на линуксе тоже важно "обновлять систему", это, как минимум, вопрос безопасности, разве нет?


  1. unreal_undead2
    24.09.2025 07:06
    #28874966

    Инфраструктура в целом должна быть готова к выходу из строя любого отдельного сервера, независимо от того, работает он сутки или год - запросы передаются на дублирующие/резервные, в это время заменяется железо.

    Когда он попытался запустить apt-get update, выяснилось, что репозитории для этой версии ОС уже давно не существуют.  

    По хорошему надо иметь локальные репозитории, куда после проверок подтягиваются обновления из апстрима, но при этом при необходимости добавляются свои пакеты с бекпортом фиксов из новых версий.


    1. PereslavlFoto
      24.09.2025 07:06
      #28877286

      Инфраструктура в целом должна быть готова к выходу из строя любого отдельного сервера

      Уточним. Инфраструктура, которая в течение десяти лет не обновлялась из-за нехватки денег, должна быть готова к выходу из строя любого из двух серверов (базы данных или бухгалтерского), дублировать который нечем из-за нехватки денег.


      1. unreal_undead2
        24.09.2025 07:06
        #28878662

        Для фирмы с штатом из директора и уборщицы логичнее арендовать инфраструктуру в облаке и не лезть в вопросы надёжности железа.


        1. NAI
          24.09.2025 07:06
          #28879230

          Сильно от экономики нищебродства зависит. В одном небольшом стартапе оказалось что держать сервер рабочую станцию в кладовке с двумя GPU на порядок дешевле чем брать в аренду самый простой GPU'ушный сервер. Бонусом - анлим на ML-эксперименты


          1. unreal_undead2
            24.09.2025 07:06
            #28879248

            Вопрос в необходимости аптайма 24/7 и стоимости простоя.


          1. fhunter
            24.09.2025 07:06
            #28879586

            А расходы на электричество считали?


            1. nitro80
              24.09.2025 07:06
              #28880296

              Они могут включаться в стоимость аренды


            1. NAI
              24.09.2025 07:06
              #28881680

              БП:750 Вт

              Расчетная пиковая: 140 Вт (GPU1) 200 Вт (GPU2), 120 Вт CPU, остальное по мелочи(HDD 1шт, 3 SSD, вентиляторы), пусть будет еще 100 Вт. Итого: ~660 Вт. В простое, очевидно, ватт 100 будет.

              30 дней *24 часа * 660 Вт = 475 кВт Это если все 30 дней под нагрузкой. Сколько там киловатт нынче стоит в однотарифном режиме? 5 р./7р.? пусть 7р. итого 3500 р. В простое 75кВт/мес. или 500 р. Вот вам вилка. Двухтарифность добавьте сами.

              За 3500 ЦОД предложит выделенный сервер с 1-2 CPU(8p) 16/32 Гб и 1-2 Тб. Ни о каких ГПУ внутри и речи не будет.

              Каллок за 3500 тоже никто не предоставит - 1U в среднем от 5000 начинается, плюс каждые 100 Вт (сверх 200) это +500-700 р. Итого размещение нашего сервера обошлось бы в 10к

              ---

              Так что наш сервер в кладовке окупился за 1-1.5 года. С учетом того что мы еще смогли урвать на авито A4000х16Gb за 45к (посмотрите сколько они сейчас стоят), так вообще щииикарно.

              Да, т.к. он в кладовке, доступность не 99.99, а 95%(условно) и то без чего нельзя прожить пару часов на нем ессно не стоит.

              И вроде все счастливы - бизнес не платит конские расходы, инженеры могут экспериментировать сколько им хочется


              1. kaplson
                24.09.2025 07:06
                #28886186

                В цоде отдельно за трафик заплатить. ВПН сделать, какой-то секурити. Это все не бесплатно.

                Тарифы приводите для бизнеса тогда уж, а не для физлиц


                1. NAI
                  24.09.2025 07:06
                  #28886574

                  Тарифы для чего?

                  если вопрос про ЭЭ, то это очень холливарный вопрос, т.к. сотрудник на удаленке как бы тоже бизнесом занимается, но чет никто не требует от него платить по тарифам бизнеса.


      1. randomsimplenumber
        24.09.2025 07:06
        #28878714

        Инфраструктура, которая в течение десяти лет не обновлялась из-за нехватки денег

        На покупку инфраструктуры деньги были, а на обновление внезапно кончились ? Или просто сова-менеджер взвесила риски, и поняла, что на лошади можно нужно ехать пока не издохнет? Издохнет - деньги найдутся, а данные тушканчики руками восстановят, за зарплату.


        1. PereslavlFoto
          24.09.2025 07:06
          #28879862

          Да, на покупку инфраструктуры была субсидия от департамента.


          1. MTyrz
            24.09.2025 07:06
            #28880154

            Иначе говоря, эффективная сова сидит этажом выше, в департаменте. Знакомая картина ;)


            1. ManulVRN
              24.09.2025 07:06
              #28880390

              Это не эффективная сова, это разные статьи расходов - закупка и обновление. А от слов "нецелевое расходование бюджетных средств" любая сова в бюджетной сфере, что эффективная, что не очень падает в обморок. Причем в чувство ее приводит прокурорская проверка.


              1. MTyrz
                24.09.2025 07:06
                #28880646

                Вы правы. Просто слово "бюджет" сразу тянет за собой такой совятник, что ой.
                (хотя мне и не нравится это сравнение. Совы, которые Strigiformes, его не заслужили)


                1. PereslavlFoto
                  24.09.2025 07:06
                  #28882132

                  Обсудим этот совятник.

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

                  Теперь вы пришли в магазин и видите, что продавцы хотят украсть ваши деньги. В другом магазине тоже. И везде так. Всюду все продавцы ставят две-три цены за этот товар. Однако у вас нет и никогда не будет столько денег.

                  Как правильно выстроить покупку, чтобы заплатить за 1 товар только 1 цену или даже сэкономить при покупке?

                  Спасибо.


                  1. Sequoza
                    24.09.2025 07:06
                    #28882170

                    Всюду все продавцы ставят две-три цены за этот товар

                    Поправьте меня, если я ошибаюсь, но вроде эту штуку называют рынком.

                    Как правильно выстроить покупку, чтобы заплатить за 1 товар только 1 цену или даже сэкономить при покупке?

                    Очевидно же. Используя административный ресурс. В последнее время популярный метод, между прочим.


                    1. PereslavlFoto
                      24.09.2025 07:06
                      #28882222

                      Рынок, это для богатых. Обычные люди ищут не где рынок, а где дёшево.


                      1. Sequoza
                        24.09.2025 07:06
                        #28882452

                        Обычные люди ищут не где рынок, а где дёшево

                        Напомнило:

                        Семь шапок сшить из этой шкурки? Да не проблема.


                      1. muxa_ru
                        24.09.2025 07:06
                        #28886560

                        а где дёшево.

                        И это тоже рынок, причём, тот же самый.


                  1. mayorovp
                    24.09.2025 07:06
                    #28882184

                    Возможно, стоит отказаться от схемы оплаты "товар сейчас, деньги когда бюджет согласуют", уменьшить требования по количеству сопровождающей товар макулатуры, и заодно забыть про откат.

                    Тогда и новые, адекватные, продавцы появятся, и старые зашевелятся.


                  1. randomsimplenumber
                    24.09.2025 07:06
                    #28882410

                    Всюду все продавцы ставят две-три цены за этот товар

                    Может с вашими деньгами что то не так? Раз именно для вас такая специальная цена?


                    1. PereslavlFoto
                      24.09.2025 07:06
                      #28882808

                      В этой ветке диалога под словом «мы» понимают все бюджетные учреждения.


                      1. randomsimplenumber
                        24.09.2025 07:06
                        #28883200

                        Тогда для вас есть определенные правила, их нужно соблюдать. И про дёшево там нет.деньги выделены - потратьте и отчитайтесь.

                        Теперь вы пришли в магазин и видите, что продавцы хотят украсть ваши деньги.

                        Не ваши. Когда родители отправили вас с бидончиком за сметаной - они не предполагали, что вы будете бегать по магазинам и искать как выкроить себе на мороженку.


                      1. PereslavlFoto
                        24.09.2025 07:06
                        #28884764

                        В рамках нашей темы пример с родителями выглядит иначе.

                        Родители дали вам бидон и послали за сметаной. Они объяснили, что купить надо в самом дешёвом месте, потому что если цена будет выше минимальной, родители не смогут заплатить. У них едва-едва хватает денег. А чтобы купить мороженку, вы должны, кроме школы, кружковых занятий и помощи по домашнему хозяйству, ещё и работать по вечерам. Например, говорят родители, вы можете за деньги продавать копии своих диктантов.


                      1. randomsimplenumber
                        24.09.2025 07:06
                        #28885486

                        Они объяснили, что купить надо в самом дешёвом месте

                        Ну, допустим, тендер. Не аукцион же. Кто предлагает цену больше - выиграть не может.


                      1. ildarz
                        24.09.2025 07:06
                        #28886216

                        Кто предлагает цену больше - выиграть не может

                        Есть вполне встречающаяся на просторах нашей Родины схема, когда крупные игроки сговариваются, а мелкие не в состоянии удовлетворить формальным условиям тендера (всякие там наличия подтвержденных компетенций и все такое). Убрать такие условия тоже нельзя, потому что тогда хрен отобьешься от мошенников или просто некомпетентных поставщиков. Распространяется, кстати, не только на тендеры от госов.


                  1. MTyrz
                    24.09.2025 07:06
                    #28887530

                    Первый вопрос: если во всех магазинах цена х2 ~ х3 от той цены, которую знаю я - откуда я знаю эту цену?


  1. ky0
    24.09.2025 07:06
    #28875046

    PCI DSS с недоумением смотрит на хосты с аптаймом больше 3-4 месяцев.

    Ну и в целом, кажется, "работает - не трогай" в 21 веке - удел замшелых ретроградов, которые не до конца понимают, "как оно там унутре работает".


    1. select26
      24.09.2025 07:06
      #28876862

      А какому конкретно пункту стандарта противоречит аптайм более 3-4 месяцев?

      p.s. как PCI админ смотрю с недоумением на такие заявления. Меня бы порвали на части, если бы мои Linux хосты имели такой аптайм.


      1. ky0
        24.09.2025 07:06
        #28876930

        6.3.3 All system components are protected from
        known vulnerabilities by installing applicable
        security patches/updates as follows:

        • Critical or high-security patches/updates
        (identified according to the risk ranking process
        at Requirement 6.3.1) are installed within one
        month of release.
        • All other applicable security patches/updates are
        installed within an appropriate time frame as
        determined by the entity (for example, within
        three months of release).

        Продолжайте смотреть с недоумением :) Что вообще плохого в низком аптайме хостов? В наше время все более-менее пригодные к продукционному использованию системы умеют бесшовно мигрировать при плановых техработах.


        1. lexore
          24.09.2025 07:06
          #28879014

          PCI-DSS регламентирует требования к накатыванию обновлений, но не к перезагрузке. Установка обновлений необязательно должна сопровождаться перезагрузкой.


          1. ky0
            24.09.2025 07:06
            #28879140

            Мы изначально говорим про хосты с Linux. Для применения новой версии ядра в общем случае нужна перезагрузка.


            1. lexore
              24.09.2025 07:06
              #28879214

              Обновления могут и не затрагивать ядро. Обновления бывают и для обычных пакетов. Поэтому, не очень корректно говорить, что если хост не обновлялся 3-4 месяца, то это сразу противоречит требованиям PCI-DSS.


              1. DMGarikk
                24.09.2025 07:06
                #28879246

                Поэтому, не очень корректно говорить, что если хост не обновлялся 3-4 месяца, то это сразу противоречит требованиям PCI-DSS.

                если хост не перезагружался 3-4 месяца то вероятность того что требования установки апдейтов не соблюдаются при этом почти 100%

                А ставить апдейты без перезагрузки кстати чревато, вот запущена у вас софтина, вы часть пакетов обновили...и чё надо софтину рестартить, вручную это делать? вести список обновленных пакетов и сервисов которые надо обязательно перезапустить, чтобы они не использовали старую версию при уже накаченной новой? кмк тут появляется состояние нестабильности которое отслеживать сильно сложнее чем сервак ребутнуть


                1. fhunter
                  24.09.2025 07:06
                  #28879594

                  Во многих случаях это может делать автоматика пакетного менеджера. (Скрипт написать который это делает - тривиально, если dlopen не используется).


                  1. DMGarikk
                    24.09.2025 07:06
                    #28879618

                    а что она сделает, автоматика то? обновить полностью систему она не сможет, и оставлять ситуацию когда апдейты поставили но работающий софт работает не старых версиях и непонятно когда это изменится - нельзя


                    1. fhunter
                      24.09.2025 07:06
                      #28879768

                      Получить список зависимостей софта не использующего dlopen для подгрузки модулей - просто.
                      (ldd по модулям, берём список библиотек, прогоняем по ним apt-file, получаем список пакетов. Если ваша кастомная софтина не в репозиториях - вешаем dpkg hook который перезапустит сервис.

                      Собственно ubuntu, например, умеет спрашивать - какие сервисы рестартовать при апдейте, почему не вписаться в эту систему.

                      Более того - в /proc у вас есть все замапленные файлы процесса ;-)


                      1. max9
                        24.09.2025 07:06
                        #28879870

                        Собственно ubuntu, например, умеет спрашивать - какие сервисы рестартовать при апдейте, почему не вписаться в эту систему.

                        для любых линкусов на самом деле доступно - https://github.com/liske/needrestart ну или почти для любых, маргинальщину не использующую rpm/deb вычеркиваем


                      1. DMGarikk
                        24.09.2025 07:06
                        #28880460

                        маргинальщину не использующую rpm/deb вычеркиваем

                        ага, ту самую которая на проде работает которую программеры программят и энтерпрайз покупает

                        мы опять про сервисы уровня nginx/apache/smtpd говорим?


                      1. max9
                        24.09.2025 07:06
                        #28880692

                        и какой же не rpm-deb лынукс покупает енторпрайз? озвучите?


                      1. mayorovp
                        24.09.2025 07:06
                        #28881546

                        Линукс-то как раз rpm-deb, а вот те программы, которые на этом линуксе запускаются - нет.


                      1. max9
                        24.09.2025 07:06
                        #28881572

                        ну тут отдельный вопрос кто неосилил пакетный менеджер (видимо предки тех, кто сейчас в докеры пакуют). на моей памяти это nvidia (и то дистры научились), рейдовые тулы и прочий оракл. если у вас самсэм-савсэм кровавый, никто же не мешает запекеждривать самому и получить все бонусы.


                      1. navion
                        24.09.2025 07:06
                        #28881622

                        У IBM куча софта идёт со своими инсталлерами вместо пакетов.


                      1. DMGarikk
                        24.09.2025 07:06
                        #28886098

                        никто же не мешает запекеждривать самому и получить все бонусы.

                        "За это не платят" (с)

                        нет, на самом деле можно так сделать, но это потом будет сложно поддерживать (вы уволитесь, ваш зам тоже, а те кто придет потом угорят в таком инструментарии разбираться)

                        а всё ради чего? чтобы сервак не ребутать? а в чем профиль админа то? нивчем, а бизнес и так готов штатно делать окна сервисных работ для некоторых сервисов


                      1. max9
                        24.09.2025 07:06
                        #28886160

                        "За это не платят" (с)

                        на самом деле все проще. если у вас в ансиблах и иже с ними забиты строки apt-get upgrade && systemctl restart whatever и вас не парит отсутвие авторестарта и неподдержка тулы needrestart.

                        либо парит и тогда вы расписываете риски, которые может принести неперезапущенный softwarename при обновленном glibc где обнаружился CVSS10. и тогда резко находятся ресурсы.

                        нет, на самом деле можно так сделать, но это потом будет сложно поддерживать (вы уволитесь, ваш зам тоже, а те кто придет потом угорят в таком инструментарии разбираться)

                        я не знаю как там в непрофильных конторах - у нас все пэкджирование завернуто в конвеер и прекрасно документировано. хоть вся команда уволится, разобратся будет элементарно.

                        а всё ради чего? чтобы сервак не ребутать? а в чем профиль админа то? нивчем, а бизнес и так готов штатно делать окна сервисных работ для некоторых сервисов

                        его так или иначе ребутать из-за кернела и микрокода CPU. я про то, чтоб не ребутать когда не надо.


                      1. fhunter
                        24.09.2025 07:06
                        #28881332

                        Спасибо, я забыл как пакет звался.


                      1. max9
                        24.09.2025 07:06
                        #28881564

                        там не за что. спасение на самом деле, оч часто используем


              1. ky0
                24.09.2025 07:06
                #28880650

                Я говорю по своему опыту - за три года работы в финтехе с ежеквартальными обновлениями пакетов на хостах не было ещё ни разу, чтобы линукс не попросил перезагрузиться.


          1. AlexeyK77
            24.09.2025 07:06
            #28879174

            долгий аптайм означает одно: BCP нормально не тестировался, что еще хуже для современных аудиторов, т.к. это базовый процесс.


        1. ildarz
          24.09.2025 07:06
          #28879988

          6.3.1 в явном виде говорит, что риск надо оценивать "с учетом потенциального влияния". Уязвимость может иметь сколь угодно высокий рейтинг, но если конкретно ваша инфраструктура такова, что она не может быть легко проэксплуатирована (например, вообще не попадает в поверхность атаки) или ее эксплуатация не может повлечь тяжелых последствий, то она просто не будет классифицирована как критичная, и, как следствие, установка патча в течение месяца не будет обязательной. А срок установки некритичных - "for example", у вас может быть один example, у кого-то другой, и никакие стандарты это не нарушает.


    1. muxa_ru
      24.09.2025 07:06
      #28880538

      которые не до конца понимают, "как оно там унутре работает".

      "Софт нормально сделать не могут и своё рукожопство прячут за периодическими ресетами", мы всё правильно понимаем?


      1. singerfox
        24.09.2025 07:06
        #28880736

        Люди, которые пишут софт и люди, которые его эксплуатируют - это разные люди (в подавляющем большинстве случаев). А ещё люди, перезагружающие сервера - чаще всего не первые и не вторые.


  1. Cyber_Griffin
    24.09.2025 07:06
    #28875670

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


  1. Cyber_Griffin
    24.09.2025 07:06
    #28875674

    Про DNS-кэш — чистая правда! Сколько раз сталкивался: 'у меня не работает', а оказывается, nscd закэшировал старый IP. Теперь всегда первым делом его чищу


    1. Black_Shadow
      24.09.2025 07:06
      #28878712

      Про кэш DNS - правда только для тех, кто не знает, как работает DNS.


      1. max9
        24.09.2025 07:06
        #28879880

        а если еще почитать умные книги про DNS то можно открыть сакральное знание - как корректно мигрировать записи, чтобы вот такого не возникало :)


        1. fluk1t
          24.09.2025 07:06
          #28881978

          А не подскажете такие книжки? Да и в целом, что читать по сетям? Я неиронично, если что.


          1. max9
            24.09.2025 07:06
            #28882002

            кажется орелевская классика была. но про сеть это чуть другое. и да, одно дело это теория в книгге, другое дело разбирать сетевку на практике, жизнь, зараза куда богаче.

            я еще завтра поищу, где-то на хабре годнота про DNS проскакивала, но там прям деньги жег народ организовывая все. я прям оргазм испытал, читая, как все грамотно делают.

            в целом тут рецепт для митигации кэша простой - уменьшаем TTL на половину до 0 ступенчато. на 0 переключаем записи и обратно.


          1. max9
            24.09.2025 07:06
            #28883822

            нашел хабровскую https://habr.com/ru/company/ozontech/blog/722042


          1. edo1h
            24.09.2025 07:06
            #28886246

            цикл статей был «сети для самых маленьких», или типа того. вроде бы даже на хабре


  1. select26
    24.09.2025 07:06
    #28876928

    Я начал работать официально как сисадмин в 1998 году. До этого баловался.

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

    Простое выключение-включение. «Феникс» больше не взлетел. RAID-контроллер решил, что с него хватит, а заодно прихватил с собой пару дисков из массива

    Я никак не могу уловить связь uptime сервера с надёжностью оборудования. Что бы изменилось, если бы сервер по расписанию перезагружался каждую ночь? Лиски бы проработали дольше? Или контроллер? Может вместо перезагрузки следует настроить корректный мониторинг дисков и контроллера? Сейчас для этого полно вариантов.

    Плановые, регулярные перезагрузки — это не признак нестабильности системы (как во времена Windows 9x), а важнейшая проверка ее здоровья. Это единственный надежный способ протестировать скрипты автозапуска, выявить скрытые проблемы с железом и применить обновления ядра.

    Вообще, по моему, дичь.

    Есть системы, от которых требуется uptime, измеряемый годами.

    Способ протестировать скрипты автозапуска, далеко не единственный. Есть staging environment. Более того, я админил до нескольких сотен физических серверов и тысячи виртуальных - даже не представляю что нужно сделать, чтобы при штатном обновлении стабильной ветки OS, сломать загрузку.

    Ядро давным давно уже обновляется без перезгрузки.

    О каких скрытых проблемах железа идет речь, я не понимаю. Если инженер обладатель профильного образования, то он знаком с теорией надежности и методикой оценки отказов. Если не обладает - всегда можно ознакомится.

    Секретов тут никаких нет: мониторинг для предсказаний отказов и резервирование. За последние 50 лет ничего нового не придумали. И регулярные перезагрузки тут вообще никаким боком не вписываются.

    В телекоме есть железки (сам знаю, я из телекома вырос), которые работают больше 10 лет в uptime. У меня есть серверы с uptime более 5 лет. Это нормально. Ненормально, если такие серверы необслуживаемые и с кучей уязвимостей, которые могут быть эксплутируемы.

    В общем, я действительно в растерянности. Такая статья - и такой бред. Хорошо, что мои преподаватели уже не прочтут..

    В следующий раз, когда вы увидите сервер с аптаймом в 1000 дней, не гордитесь им. Пожалейте его. И запланируйте ему достойные проводы, заменив его молодым и свежим клоном. В этом и есть дзен современного администрировани

    Кошмар просто.. наверное такими же рекомендациями руководствовались админы и разработчики последнего Фобоса и лунного модуля. "Перезагрузите ваш компьютер " - это в принципе не везде работает!

    А еще есть системы жизнеобеспечения и энергетика!


    1. mayorovp
      24.09.2025 07:06
      #28878808

      Ядро давным давно уже обновляется без перезгрузки.

      А это тогда почему выводится периодически при подключении по ssh?

      *** System restart required ***


      1. navion
        24.09.2025 07:06
        #28879622

        Наверное забыли включить лайвпатчинг.


        1. max9
          24.09.2025 07:06
          #28879894

          который требует про в убунтах и мерзости snapd


        1. mayorovp
          24.09.2025 07:06
          #28879902

          А оно ещё и не по умолчанию включено?..


          1. navion
            24.09.2025 07:06
            #28880018

            Оно несовместимо с kprobe, наверное поэтому выключено. Но даже у RHEL ядро обновляется раз в неделю и на критичных системах без этой штуки жизни нет.


          1. dartraiden
            24.09.2025 07:06
            #28880922

            В убунтах оно требует ключ. Который нужно сначала получить у каноникла (и бесплатно этот ключ будет работать лишь на 5 машинах).


    1. edo1h
      24.09.2025 07:06
      #28878902

      Ядро давным давно уже обновляется без перезагрузки

      Ну расскажите мне как перелезть с 6.1 на 6.18 без перезагрузки.
      А апгрейд имеет смысл, например, для свежих систем на Intel/AMD очень много всего допилено. Или, например, свежая версия софта может хотеть свежее ядро (например, io_uring пилят постоянно)


      1. ky0
        24.09.2025 07:06
        #28879164

        Есть два типа админов: из 1998 года старающиеся "лишний раз не трогать" и трогающие с последующей диагностикой возникающих проблем, если они есть - но не в авральном режиме ночью раз в три года, а в спокойной обстановке.


    1. MaximRV
      24.09.2025 07:06
      #28879224

      жесткие диски тоже с подшипниками, шпиндель может и не раскрутиться после остановки.


    1. NAI
      24.09.2025 07:06
      #28879264

      А еще есть системы ... и энергетика!

      в энергетике все попроще, там есть ППРы (планово-предупредительный ремонт) - раз в год-полтора-два, в любой системе начинают дергать\обновлять\заменять\отключать\устранять замечания. В том числе и ЗИПы проверяют.


    1. Spyman
      24.09.2025 07:06
      #28880580

      Я никак не могу уловить связь uptime сервера с надёжностью оборудования. Что бы изменилось, если бы сервер по расписанию перезагружался каждую ночь? Лиски бы проработали дольше? Или контроллер?

      Связь простая - сдохло бы раньше - "по расписанию", а не когда перезагрузка случилась нештатно (видимо подразумевается в статье).

      А так, полностью с вами согласен. [Joke] Для меня тоже выглядит как "заказная статья от разработчиков windows server" [\Joke]


    1. 0xdead926e
      24.09.2025 07:06
      #28882848

      даже не представляю что нужно сделать, чтобы при штатном обновлении стабильной ветки OS, сломать загрузку.

      не так давно в стейбле дебиана ломался 32-битный grub-efi. настолько, что даже вручную загрузить ядро нельзя было- нужен был внешний загрузчик. наткнулась как-то на атомном планшете, у которого uefi строго 32-битный и у него таки села батарейка.

      ну а говноплатники на армбиане, которым в апдейтах прилетает ядро без драйвера то на сеть, то на контроллер sdmmc (на котором висит корневой диск)- ваще классика.


  1. gecube
    24.09.2025 07:06
    #28876988

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


    1. Sequoza
      24.09.2025 07:06
      #28879444

      Позвольте немного подушнить. Мы умираем не затем, чтобы не накапливать ошибки, а как раз из-за того, что ошибок стало слишком много. Мы, своего рода, Arch дистры. А рождение - бэкап до состояние, когда количество багов - приемлимое.


      1. Spyman
        24.09.2025 07:06
        #28880622

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


        1. Sequoza
          24.09.2025 07:06
          #28881094

          Напрашивается философский вопрос. Механизм старения - баг, который пока не пофиксился или фича? Сервер-то 1000 дней работает и ничего. Смысл его трогать? Стоит менять, когда новые requirements подвезут.


          1. Spyman
            24.09.2025 07:06
            #28882992

            У большинства живых существ - механизм старения фича. А у серверов баг. Эволюция жизни направлена на выживание вида - а это эффективно можно делать только устраивая ротацию и отыскивая слабые особи, эволюция серверов направлена на максимизацию надёжности - а на 100% надёжный сервер - работает до тех пор, пока его не выключат.


            1. muxa_ru
              24.09.2025 07:06
              #28886572

              У большинства живых существ - механизм старения фича. А у серверов баг.

              Это одно и то же.

              Система в процессе жизни обрастает разными багами, просто в одном случае это принято называть "старение", а в другом "легаси".


    1. Spyman
      24.09.2025 07:06
      #28880616

      Вопрос "зачем" предполагает наличие воли. А мы скорее рождаемся и умираем "почему" (потому что всё предыдущие поколения наших предков оставили потомство следуя этой последовательности, а все, кто потомства не оставил - не наши предки).

      Ну либо наличие бога предполагается)


  1. PerroSalchicha
    24.09.2025 07:06
    #28878450

    По поводу скрытых повреждений софта и физической деградации железа - а какая разница, когда сервер упадет, во время плановой еженедельной перезагрузки, или во время плановой/внеплановой перезагрузки раз в пару лет? Ну, кроме того факта, что во втором случае у вас была пара лет спокойной жизни без ночных авралов.


    1. gecube
      24.09.2025 07:06
      #28878654

      В первом случае ты готов, к тому, что что-то пойдет не так. И бизнес тоже в курсе.

      Во втором случае ты якобы спокоен, но весь operations - это решение всяких неожиданных проблем, 24/7. Так что от пейджера уже скоро вздрагивать начинаешь.


      1. edo1h
        24.09.2025 07:06
        #28878798

        Бизнес в курсе? Его волнует не работоспособность сервера, а работоспособность сервиса


        1. Okeu
          24.09.2025 07:06
          #28879162

          Сервер ожидаемо, по расписанию, ребутался в 12 ночи и не поднялся - у вас вся ночь впереди на решение инцидента.
          Сервер ребутнулся днем в разгар рабочего дня и не взлетает - инцидентище)

          Думаю концептуально разница в этом)


          1. edo1h
            24.09.2025 07:06
            #28879218

            'Сервер ребутнулся днем в разгар рабочего дня и не взлетает

            Тут два варианта. Или нагрузка перенесена на другие серверы, и пользователи не замечают проблем, или бизнес устраивает простой (на самом деле вполне обычная ситуация, зачастую простой сервера условно на один день в год стоит куда меньше, чем потребуется на резервирование).


          1. fhunter
            24.09.2025 07:06
            #28879612

            Сервер ожидаемо, по расписанию, ребутался в 12 ночи и не поднялся - у вас вся ночь впереди на решение инцидента.

            Сколько там в стране часовых поясов? А если у вас глобальный сервис?


          1. PerroSalchicha
            24.09.2025 07:06
            #28880678

            Сервер ребутнулся днем в разгар рабочего дня и не взлетает - инцидентище)

            Инцидентище в разгар рабочего дня, как по мне, это куда попроще, чем инцидент в разгар ночи :) Тем более что сейчас еще надо очень-очень постараться найти такой сервер, чтобы он одновременно был и критичен для бизнеса, так, чтобы его простой в течении нескольких часов приводил бы к каким-то финансовым потерям, и при этом не был бы хорошо продублирован.


            1. Okeu
              24.09.2025 07:06
              #28880808

              тут основной акцент не на времени все-таки) А в ожидаемости.
              Пусть даже ребут в 11 утра ежедневно.
              Как только сервер придет в состояние Х, при котором он уже будет не в состоянии стартануть - точка отказа случится предсказуемо на следующий день.
              А вот иной кейс - когда сервер не ребутался очень долго, вы проводите штатные работы "ща на 5 минуток памяти доткнуть потушим" и тут у вас случается факап. Причем диагностика несколько затягивается из-за того, что первым делом начинаешь "откатывать изменения" думая, что из-за них и произошел сбой (а на самом деле нет)


              1. PerroSalchicha
                24.09.2025 07:06
                #28881372

                Как по мне, если ты ребутишь сервер, который ты не ребутил чуть более чем никогда на своей памяти, это само по себе событие, которое у тебя должно вызывать некую настороженность by default.


                1. Okeu
                  24.09.2025 07:06
                  #28881560

                  вот об этом и речь же)
                  Что если условно у тебя что-то ребутится регулярно, то и точка отказа становится... я даже не знаю как правильно это сказать...
                  пусть будет "более детерминированной", чтоли


  1. mayorovp
    24.09.2025 07:06
    #28878752

    В разделе про DNS не хватает выходного кеша хостера. Сбросить его невозможно, только ждать пока соблагоизволит обновиться…


    1. fhunter
      24.09.2025 07:06
      #28879620

      А грамотно ставить TTL DNS-записей - уже харам?


      1. mayorovp
        24.09.2025 07:06
        #28879932

        Во-первых, "грамотно" - это как? 5 секунд ставить глупо, а всё что больше - ведёт к проблемам.

        Во-вторых, от авторитативного сервера как-то ожидаешь, что он среагирует на изменение настроек сразу же, а не спустя TTL.


        1. fhunter
          24.09.2025 07:06
          #28880852

          Во-вторых, от авторитативного сервера как-то ожидаешь, что он среагирует на изменение настроек сразу же, а не спустя TTL.

          Только это нарушает спецификацию DNS, если я правильно помню. Опять же - даже если у вас есть авторитативный сервер - напрямую он не даёт ответов клиентам, они всё равно получат это из кэшей по дороге.

          Во-первых, "грамотно" - это как? 5 секунд ставить глупо, а всё что больше - ведёт к проблемам.

          В смысле? У вас есть допустимый по SLA период недоступности сервиса. Если у вас по SLA, допустим 99.9% доступности - это 9 часов недоступности в год. Ставите TTL в 1/2 часа и проблем нет. У вас есть возможность упасть ~18 раз в год и не нарушить SLA.
          Если у вас более высокие требования надёжности - то тут уже вы будете делать более сложные решения.


      1. DaemonGloom
        24.09.2025 07:06
        #28880024

        А некоторые сервисы настраивают кеш так, что он игнорирует TTL записей. Натыкался уже несколько раз на такие ситуации. TTL - минута, все остальные клиенты уже используют новый адрес. Но за определённым провайдером - спустя час всё ещё получали старый адрес от провайдерского кеша.


        1. fhunter
          24.09.2025 07:06
          #28880856

          Ну так это не норма. (Некоторые провайдеры и не такое творят).


  1. edo1h
    24.09.2025 07:06
    #28878818

    Честно говоря, по-моему обоснование противоречит тезису. Если у вас сделано «по уму» и от работоспособности отдельного сервера не зависит работоспособность сервиса, то какая разница какой аптайм, и, соответственно, зачем его искусственно ограничивать? Есть повод перезагрузиться (например, технологии обновления ядра без перезагрузки пока в зачаточном состоянии) — перезагружаемся, нет — так и зачем?


  1. anzay911
    24.09.2025 07:06
    #28878858

    В Ubuntu Pro есть Livepatch, позволяющий устанавливать обновления безопасности в работающее ядро без перезагрузки.


    1. kma21
      24.09.2025 07:06
      #28879390

      Такой механизм есть не только у убунты. Это работает не для всех обновлений и не всегда.


  1. Cubus
    24.09.2025 07:06
    #28879028

    Всегда старался при плановых работах заодно сбросить аптайм, если можно. Почему? Да потому что я видел зависание crond при больших аптаймах на 4 (четырёх) разных ОС:
    - Solaris 5.8
    - HP-UX 11.23
    - AIX не помню какой версии
    - И наш любимый Linux тоже


    1. imotorin
      24.09.2025 07:06
      #28881030

      Solaris 5.8 это очень давно,
      на 5.9 впрошлый год видели аптайм 10 лет,
      но единственный диск посыпался, прилось перегружать, и собирать зеркало на SVM
      а актуальная 5.11.4.84, lf


      1. Cubus
        24.09.2025 07:06
        #28881150

        Я исхожу из того, что то, что я наблюдал такое давно, совершенно не означает, что похожая проблема не может проявиться и в современном софте. Потому и страхуюсь.


        1. navion
          24.09.2025 07:06
          #28881644

          В современном софте переполнение счётчиков встречается регулярно, причем разработчики его редко ловят - у них тестовая среда перезагружается чаще рабочих сред заказчиков.


  1. JustTry13
    24.09.2025 07:06
    #28879066

    Интересная статья, спасибо.

    Почитать бы еще подобное в контексте разработки и деплоя программ. Потому что тут тоже может весело:

    • Спустя пол года решили доработать сервис. Случайно добавили баг. Решили откатить на старую версию, а ее уже нет. Из-за политики хранения образов, старая версия уже давно была удалена.

    • Начали деплоить новую версию приложения, которое до этого работало 3 месяца без доработок. Оказалось, что за это время поменялись правила деплоя, и приложение сходу не завелось. Тут оказалось проще - поменялось требование к количеству реплик.


  1. mayorovp
    24.09.2025 07:06
    #28879126

    Добавлю историю про перезагрузку.

    Повадилась одна виртаулка после перезагрузки не стартовать контейнеры докера. И после очередного подарка от Яндекса в виде массовой перезагрузки виртуалок решил я наконец-то разобраться что там творится. Попросил доступ и пошёл изучать ситуацию.

    Контейнеры докера не стартовали потому что сам докер не мог стартовать. При этом вручную докер без проблем запустился. С мыслью "что за ерунда?" я полез изучать логи. А в логах докер не мог создать какой-то нужный ему файл потому что файловая система была только для чтения.

    Первой мыслью был искорёженный порядок зависимостей в юнитах, из-за которой докер запускался слишком рано. Однако, аномалий в unit-файлах не обнаружилось, конфигурация была похожа на стандартную. Симтомы проблемы не гуглились. Я уже совсем закопался в тонкости архитектуры systemd, но потом догадался перезагрузить виртуалку ещё раз. Догадка была верна - корневая ФС так и осталась рид-онли, никакой systemd её и не собирался делать нормальной. Почему же тогда до этого такой проблемы не было? Ну, после угрозы применения пыток коллега, который давал мне доступ, сознался - он сделал remount корневой ФС, потому что иначе не получалось создать мне учётку на сервере.

    И так, проблема сервера была не в порядке юнитов, а исключительно в корневой ФС. Но где? Первым делом посмотрел в fstab, нет ли там ключа ro. Ключа не нашёл, как и вообще записей. "Ого!" - подумал я, "неужели и fstab уже в окончательно systemd переехал?" Полез изучать systemd дальше, но с ходу почему-то не нашёл где вообще точки монтирования были настроены. Пришлось идти другим путём и выяснять кто вообще в systemd отвечает за монтирование корневой ФС и что с ним случилось. Нашёл нужный юнит, а дальше снова облом - в логах ни единой ошибки. И даже прямой запуск команды systemd-remount-fs ничего не делает (и снова ничего не делает без единой ошибки).

    Спустя неокторое время до меня наконец-то дошло, что эти два тупика, в которые я упёрся, на самом деле прекрасно складваются в общую картину: systemd-remount-fs ничего не делает именно потому, что fstab пуст. Добавление туда корректной записи для системного диска решило проблему, и проклятая глючная виртуалка стала самой обычной.

    Осталось понять как вообще этот файл оказался пуст? Ну, точно уже не узнать, но на сервере ранее отключали подкачку. Видимо, в процессе работ случайно удалили лишнюю строчку.


    1. JBFW
      24.09.2025 07:06
      #28879760

      Ну, после угрозы применения пыток коллега, который давал мне доступ, сознался - он сделал remount корневой ФС, потому что иначе не получалось создать мне учётку на сервере.

      И так, проблема сервера была не в порядке юнитов, а исключительно в корневой ФС.

      Неет, проблема была в кривых руках. Которые, в том числе, снесли fstab, и свалили всё на "устаревание"...


      1. mayorovp
        24.09.2025 07:06
        #28879940

        Чинить кривые руки, которые уже снесли fstab, несколько бесполезно. Особенно если это руки неизвестного, потенциально уже уволившевося сотрудника.


  1. ogost
    24.09.2025 07:06
    #28879462

    По-моему где-то здесь недавно я рассказывал как в бытность админом сдох один из серверов биллинга в местной телеком конторе. Суть в том, что в серверной стояли обычные сплит офисные сплит-системы, которые были и так на износе и постоянно выходило из строя. Приходилось открывать окна в серверной и туда вечно наметало пыли. Руководство отмахивалось, мол и так работает же (контора полу-государственная и руководство менялось регулярно с выборами. Новая власть - новые люди. Старались оставить проблемы на преемников). Пока не выключился старичок от IBM, уже не помню из-за чего, и не проснулся. Сдох один из кулеров от кучи пыли и биос вываливался с ошибкой. "Новый" кулер заказали в китае на барахолке, но ехать он должен был чуть ли не месяц и нет гарантий, что он рабочий. Старый чистили - не помогло. Тогда я раскрутил проблемный кулер мощной воздуходувкой и включил сервер. Биллинг через некоторое время поменяли на новый, руководство наконец-то докумекало и в серверной поставили нормальные промышленные системы охлаждения.


  1. scientificus-emigrans
    24.09.2025 07:06
    #28879776

    Знакомая ситуация. В лаборатории где я работаю использовался сервер для расчетов стоящий в датацентре. Uptime был 7(!) лет. В определенный момент его стало просто страшно перезапускать -- кто знает поднимется ли он после? Так работает -- и хорошо. Однако, заявку на рекорд грубо обломали электрики, затеявшие ремонтные работы в датацентре. Мы пальцы скрещивали, чтобы он поднялся)

    Кстати, там где реально требуется отказоустойчивость (коммерческая авиация), есть как минимум два управляющих компьютера, и они переключаются после каждого полета, с правого на левый и обратно. Это сделано специально, чтобы любые проблемы вылезали как можно раньше, а не в ситуации, когда в полете сдох основной, а резервный сдох еще полгода назад, но про это никто не знал. А теперь вспомните вашу фирму. Допустим, в ней есть основной и резервный сервер. А вы уверены, что при отказе основного резервный способен полностью принять все его задачи?


    1. Moog_Prodigy
      24.09.2025 07:06
      #28880382

      Там где реально требуется отказоустойчивость - используется троирование с мажоритированием по принципу 2 из 3. Можно любое нечетное число узлов. И все работает строго параллельно а не стоит где-то там "в резерве".


  1. JBFW
    24.09.2025 07:06
    #28879872

    Как обычно, на самом деле всё не совсем так, хотя и похоже )

    Есть проблема физического износа: те же вентиляторы, диски и тому подобное. Да, они постепенно выходят из строя, и при этом как правило именно включение-выключение их и добивает.
    Хотите добить быстро - выключайте почаще, это не даст им незаметно состариться, умрут молодыми.

    Но есть другое решение: регламент плановой замены - раз в N месяцев старые диски выкинули, новые диски поставили, несмотря ни на SMART, ни на чуйку, ни на что. По регламенту.

    Есть проблема неактуальности версий: уже вышла Proga 12.6.3 , а у нас до сих пор 8.0.0!
    Срочное обновление!!

    Нет, срочно по рукам лопатой. Потому что при этом есть очень хорошая вероятность сломать совместимость с чем-то, что казалось бы ну вот вообще никак не связано.
    Готовим новое железо (или виртуалку на старом), устанавливаем новую версию, ТЕСТИРУЕМ - а потом миграция системы на новую версию.

    Да, и даже ядро ОС. Тем более ядро ОС.

    А как же безопасность?! Ведь в старой версии, если в полнолуние криворукий дятел три раза щелкнет клювом - в систему может пролезть сетевой червь?!

    Ну если криворукий дятел знает, что в систему может пролезть червь - ну поставь ты сначала вокруг защиту, не будь криворуким дятлом! И даже если не знаешь - представь, что может - и поставь.
    Потом - см.выше - новая инсталляция, тестирование, миграция.

    Да, и про плановую замену не забываем, чтобы у кулеров не вырастала борода из пыли и диски не летали.

    И остается вопрос с кривыми программами, которые жрут память, гадят под себя на диск какашками временных файлов, и оставляют зомби по углам.
    Штош, видимо на тех серверах, у которых аптайм годами, такие просто не водятся.
    Либо отцы-программисты их пролечили, либо админ-владелец решил выбрать другое решение задачи.

    Как-то так.

    А не вот это вот "в любой непонятной ситуации - перезагружайся!"


  1. The_KOPACb
    24.09.2025 07:06
    #28880032

    админ унаследовал несколько Debian-серверов с аптаймом 1300+ дней. Когда он попытался запустить apt-get update, выяснилось, что репозитории для этой версии ОС уже давно не существуют.

    А, ммм. Про миграцию релизов с deb.debian.org на archive.debian.org мы не слышали.

    Не без плясок, но с вероятностью 85% можно взять debian buzz и обновиться до trixie. squeeze - trixie - 99%.
    https://archive.debian.org/debian/dists/

    Один коллега рассказал, как планово перезагружал vSphere-хост с аптаймом 300+ дней. После ребута система не нашла загрузочный USB-диск — он оказался поврежден. Гипервизор для клиента просто перестал существовать.

    Другой админ с ужасом смотрел на SAN-хранилище с аптаймом в 1400 дней. Никто не решался его трогать, потому что все понимали: при перезагрузке есть неиллюзорный шанс столкнуться с массовым отказом старых дисков.

    Классика жанра: сервер выключают для замены одного сбойного диска в RAID-массиве (не hotswap). После включения умирает еще один диск.

    Что такое "наработка на отказ", дата TEC, регулярные тесты SMART, а также мониторинг raw_read_error_rate.

    Но вообще, если почитать свитки древних, там всё написано. И как часто харды менять, и как часто серваки обновлять, и как часто новые покупать.

    Но аптайм 300 дней конечно зло, да.

    В следующий раз, когда вы увидите сервер с аптаймом в 1000 дней

    Аптайм 1к дней на новом серваке - дык там по аптайму запас ещё на 1-2к дней, не считая хардов. Но харды как будто можно заменить не роняя аптайм.

    Другой вопрос что ядро надо иногда обновлять, но как будто придумали livepatch.


    1. The_KOPACb
      24.09.2025 07:06
      #28880680

      Это медленный и коварный процесс, когда приложение захватывает память, но «забывает» ее освободить после использования. Со временем это приводит к деградации производительности, чрезмерному использованию swap и, в конечном итоге, к падению приложения или всей системы. Это классический пример роста энтропии внутри запущенного процесса.  

      Lol, ну так-то уже лет 5 как swap > 2-4G моветон. Нормально вообще его отключать.

      И в линуксе как будто бы есть oom-killer. Сожрал много памяти - тебя убьют. systemd заново тебя поднимет, живём дальше. В винде он тоже есть, кстати.


      1. mayorovp
        24.09.2025 07:06
        #28880726

        Если бы ещё oom-killer вовремя срабатывал, обычно сожранная память вытесняет в своп страницы кода, после чего система наглухо зависает. И отключение свопа не помогает, потому что именно для страниц кода каждый бинарник - сам себе своп.

        Решение проблемы в свежих ядрах уже есть, но по умолчанию отключено.


        1. The_KOPACb
          24.09.2025 07:06
          #28880828

          у меня приложенька регуряно убивается oom-киллером в тестовой среде. терминал почти никогда не зависает. но своп отключен, если памяти >8G своп уже не нужен.
          Согласен с тем что кейс не такой же как если бы была медленная утечка памяти, но всё же.


      1. edo1h
        24.09.2025 07:06
        #28887314

        Lol, ну так-то уже лет 5 как swap > 2-4G моветон

        кто это вам сказал? у меня достаточно серверов, в которых своп не меньше ram. я не говорю уже про десктопы (вот сейчас пишу с машины, в которой 32ГБ памяти и 150ГБ свопа, из которых занято 26, но бывает и 100+) и нотбуки (если своп меньше RAM, то куда hibernate-то делать?)
        и откуда вообще пошла эта идиотская мода делать своп размером в 4ГБ при памяти 256ГБ? какой смысл в свопе на порядки меньшего размера, чем ОЗУ?


  1. nokeya
    24.09.2025 07:06
    #28880212

    Были еще известные истории как на дорогущих стоечных свичах Cisco отваливалась оперативная память после перезагрузки.


  1. Stanislavvv
    24.09.2025 07:06
    #28880598

    Вот на дебиан тянуть не надо — archive.debian.org отлично работает и позволяет доустановить пакеты или обновить систему на следующую версию. Оно, конечно, неправильно, держать такую древность, но случаи разные бывают.


  1. hallfrom
    24.09.2025 07:06
    #28881998

    Половину осилил... Народ Вы вроде взрослые а в байки верите... Большинство серверов рассчитанный на работу 24/7 в течении 4-5 лет, потому и цены у них такие космические.