проблема, до и после, подход
 

Порог принятия решения, у кого как?
Допустим, просматривается некий кирдык, в предсказуемый период
Вариант 1: превентивно разбираем ситуацию, что-то предпринимаем.
Вариант 2: кладём, когда крякнет, тогда и суетится пора пришла.
Кто по какому сценарию действует? Честно есс-но.

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

У адекватных клиентов "закупаем новый сервер заранее и переходим, не дожидаясь остановки фирмы"

У "экономных и разумно тратящих деньги" - ждём пока накроется. Затем начинается "А можно как-то срочно сделать, чтобы сегодня уже заработало?!"

2-StepanRazin > что значит "закупаем новый сервер заранее и переходим, не дожидаясь остановки фирмы" ?

Тоесть ваш вариант переход на новый сервер ? А если вопрос вовсе не в сервере а в кривезне рук администратора, 1сника и т.д.

все зависит от нужности сервиса. Если критично то 1 вариант, если это что-то незначительное или для своих нужд 2 вариант

Гражданам с рукой в кошельке, порой сложно объяснить, зачем нужно сейчас потратиться на, казалось бы, ровном месте. Таких экономистов учит жизнь. Давайте оставим их в покое.
Мне интересно поведение именно инженеров.

"Кирдык" понятие относительное конечно. Место на диске, адресный пул, состояние батареи RAID или UPS и пр. пр.. Звоночек короче.

Блины отработавшие свой MTBF, но еще крутятся.

о, кто-то наслушался умных терминов и применяет их где не надо.
А ничего, что MTBF - это статистическая величина, а не срок жизни в годах. И бу-шный диск (если он не начал сыпаться, конечно) не менее надежен, чем новый. Даже наоборот: пик выходов из строя дисков - первые 3, чуть поменьше - первые 6 месяцев.
А вообще, правильный подход такой:
1. Проанализировать всю инфраструктуру, выявить все возможные проблемы (не вдаваясь в детали, крупными блоками)
2. Оценить вероятность проблем и возможные потери от них. Оценить стоимость изменений к лучшему.
3. Решить, смириться и жить с каждой конкретной проблемой (не у каждого же сервера распределены между континентами) или что-то делать. Если что-то делать - разобрать выбранную проблему на компоненты и повторить все вышеописанное, пока не станет понятно, что конкретно делать.
А так - детство какое-то.

[quote]И бу-шный диск (если он не начал сыпаться, конечно) не менее надежен, чем новый[/quote]
Вот-вот, и об этом тоже
Про "кто-то наслушался умных терминов", ДДМ, ну не судите уже о других, ориентируясь по своей глупой башке

2КраснодарАйТи. Тут еще такой вопрос: что дешевле - купить сервер или 1сник с прямыми руками. А с точки зрения долгосрочного планирования новый сервер безопаснее: 1сник может уволиться, и если он был звездой - возникнут трудности с поиском такого же, а сервер всегда можно купить.
Хотя, конечно, я видел 8-гиговую базу данных, состоящей из единственной таблицы, которая использовалась, просто как excel-евская таблица (ни нормализации, ни индексов - ничего, еще и с опечатками) с соответствующей производительностью. И несколько минут работы абсолютно среднего SQL-щика освободили очень много ресурсов.

2harsh. Да не только в этом проблема. Вообще, подход - детство.
Если батарейка raid подходит к концу - со включенным writeback (если данные важны) этот сервер нельзя эксплуатировать. Выключаете writeback - и либо все и так нормально, либо деньги быстро найдутся.
Место заканчивается - согласовываете с руководством квоты, каждое повышение квоты - служебка с намеком на деньги.
Вы описываете какую-то дикую модель из 90-х, где админ - непонятное чудило из-под лестницы, вечно требующий деньги непонятно на что. Просто нужно ставить руководство в известность, что сколько стоит, и делать это заранее и непрерывно.

"согласовываете с руководством", точка.
Инфантильный мальчик.
Если вам не понятно о чем, гуляйте мимо. Помозгуйте между делом про MTBF.

[quote=Добрых дел мастер;43169739] Вы описываете какую-то дикую модель из 90-х, где админ - непонятное чудило из-под лестницы, вечно требующий деньги непонятно на что. Просто нужно ставить руководство в известность, что сколько стоит, и делать это заранее и непрерывно. [/quote]
Допустим речь идет о крупной компании, где IT далеко не на последнем месте и целая иерархия всевозможных эффективных менеджеров. Поставили руководство в известность и что дальше?

2krotov. А дальше - ничего. Ну, разве что, делать это регулярно, с графиками(например - свободного места) и сроками исправления. И так, чтобы можно было поднять переписку, когда все взорвется.
Я не могу из куска кремния напильником выпилить дополнительную память или жесткий диск.

Для тех у кого проблемы с концентрацией,
вынужден процитировать самого себя
[quote]Мне интересно поведение именно инженеров.[/quote]

Подчеркиваю [b]инженеров[/b], не шлюх, заглядывающих в рот пуководству на каждый чих.

[quote=harsh;43171770] Для тех у кого проблемы с концентрацией, вынужден процитировать самого себя Цитата: Мне интересно поведение именно инженеров. [/quote]
Тут от ситуации зависит:
Вариант 1 (как ДДМ):
- превентивно разбираем ситуацию, пытаемся донести до инженеров/руководства клиентов, своего руководства, у кого как, вероятных результатов наложения болта на проблему и в зависимости от решения оных:
a) кладём (подложившись перепиской), когда крякнет, тогда и суетится пора пришла.
b) что-то предпринимаем
Вариант 2: долбаем и долбаем инженеров/руководство клиентов, своё руководство до белого каления, перелезая через головы всяческих менеджеров пока либо:
a) не добьешься результата для принятия превентивных мер
b) когда крякнет, и суетиться пора уже пришла.

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

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

2krotov. А ты единственный, кому это надо? Практика показывает, что если ты будешь водить вокруг всех хороводы и уговаривать - это просто станет твоей обязанностью и головной болью. И ответственностью.
Я как-то пришел к тому, что нужно залогированная переписка, плюс - максимум один факап (а по факту, у каждого он уже был в прошлом, хотя тут кроется еще один момент: если ты оповещаешь какое-нибудь дерево - включи в копию его руководство).

2harsh. А что вы можете сделать сам? Батарейку для raid-контроллера спаять? Или за свои деньги купить?
Я думал, что все, что зависит от вас, вы уже сделали.
Или тема "я накосячил, вот думаю, исправлять или нет"?

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

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

дело не в "жопоотводе" (как мы это называли в Тандере).
Дело во внутреннем чувстве перфекционизма.

[quote=КраснодарАйТи;43167913]2-StepanRazin > что значит "закупаем новый сервер заранее и переходим, не дожидаясь остановки фирмы" ?Тоесть ваш вариант переход на новый сервер ? А если вопрос вовсе не в сервере а в кривезне рук администратора, 1сника и т.д. [/quote]

Я говорю про то, что если серверу более 5 лет, то надо планировать бюджет на его замену.
Не уповая на "авось ещё проработает".

В моём опыте (50-60 клиентов, средний размер - 20-30 компьютеров, 2-4 сервера) есть те, у кого сервер работает уже 8-10 лет, а есть те, у кого через 5.5 либо начал феерически тормозить, либо просто мать умерла.

И если фирма не может себе позволить остановку бизнес-процесса, серверы надо менять на новые по достижению ими возраста 5-6 лет

2StepanRazin.
Имхо, ни на чем не основанное утверждение. Точнее, основанное на "шаманстве".
В моей практике, были и 10-летние серваки, которые прекрасно работали, и новенькие HP-шные сервера, которые сразу лагали, и 1-летние IBM-овские лезвия, которые вдруг перестали загружаться и еще много чего.
Имхо, сервера стоит заменять на рубеже 5-7 лет из следующих соображений:
- Стоимость поддержки (если они на поддержке)
- Соотношение производительность\потребляемое электричество или производительность\место в стойке(охлаждение, прочая инфраструктура ЦОД). Это скорее актуально для больших ЦОД.
- Соотношение производительность\стоимость лицензий

А если компания не может себе позволить остановку бизнес-процесса - нужно не сервера менять, а подходить к процессу системно. Например, виртуализировать все и иметь свободные ресурсы для выхода из строя N серверов, еще лучше - репликация на удаленную площадку, может быть - в облако. Возможно - нужен ЗИП. А вообще, нужен дизастер рекавери план.

29-Добрых дел мастер > экивоки на "шаманство" это приговор квалификации.
[b]ЖЫрная[/b] точка.

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