| 0
- 02.11.2016 - 22:22
|
Порог принятия решения, у кого как? Допустим, просматривается некий кирдык, в предсказуемый период Вариант 1: превентивно разбираем ситуацию, что-то предпринимаем. Вариант 2: кладём, когда крякнет, тогда и суетится пора пришла. Кто по какому сценарию действует? Честно есс-но.     | | |
| 1
- 02.11.2016 - 23:43
| Делаем копию, разбираемся в проблеме, до статуса "крякнет" диагностируем и решаем проблему, переносим решение в продакшн | | |
| 2
- 02.11.2016 - 23:46
|
У адекватных клиентов "закупаем новый сервер заранее и переходим, не дожидаясь остановки фирмы" У "экономных и разумно тратящих деньги" - ждём пока накроется. Затем начинается "А можно как-то срочно сделать, чтобы сегодня уже заработало?!" | | |
| 3
- 02.11.2016 - 23:49
|
2-StepanRazin > что значит "закупаем новый сервер заранее и переходим, не дожидаясь остановки фирмы" ? Тоесть ваш вариант переход на новый сервер ? А если вопрос вовсе не в сервере а в кривезне рук администратора, 1сника и т.д. | | |
| 4
- 03.11.2016 - 11:06
| все зависит от нужности сервиса. Если критично то 1 вариант, если это что-то незначительное или для своих нужд 2 вариант | | |
| 5
- 03.11.2016 - 11:26
|
Гражданам с рукой в кошельке, порой сложно объяснить, зачем нужно сейчас потратиться на, казалось бы, ровном месте. Таких экономистов учит жизнь. Давайте оставим их в покое. Мне интересно поведение именно инженеров. | | |
| 6
- 03.11.2016 - 11:31
| "Кирдык" понятие относительное конечно. Место на диске, адресный пул, состояние батареи RAID или UPS и пр. пр.. Звоночек короче. | | |
| 7
- 03.11.2016 - 11:40
| Блины отработавшие свой MTBF, но еще крутятся. | | |
| 8
- 03.11.2016 - 12:11
|
о, кто-то наслушался умных терминов и применяет их где не надо. А ничего, что MTBF - это статистическая величина, а не срок жизни в годах. И бу-шный диск (если он не начал сыпаться, конечно) не менее надежен, чем новый. Даже наоборот: пик выходов из строя дисков - первые 3, чуть поменьше - первые 6 месяцев. А вообще, правильный подход такой: 1. Проанализировать всю инфраструктуру, выявить все возможные проблемы (не вдаваясь в детали, крупными блоками) 2. Оценить вероятность проблем и возможные потери от них. Оценить стоимость изменений к лучшему. 3. Решить, смириться и жить с каждой конкретной проблемой (не у каждого же сервера распределены между континентами) или что-то делать. Если что-то делать - разобрать выбранную проблему на компоненты и повторить все вышеописанное, пока не станет понятно, что конкретно делать. А так - детство какое-то. | | |
| 9
- 03.11.2016 - 12:16
| Цитата:
Про "кто-то наслушался умных терминов", ДДМ, ну не судите уже о других, ориентируясь по своей глупой башке | | |
| 10
- 03.11.2016 - 12:17
|
2КраснодарАйТи. Тут еще такой вопрос: что дешевле - купить сервер или 1сник с прямыми руками. А с точки зрения долгосрочного планирования новый сервер безопаснее: 1сник может уволиться, и если он был звездой - возникнут трудности с поиском такого же, а сервер всегда можно купить. Хотя, конечно, я видел 8-гиговую базу данных, состоящей из единственной таблицы, которая использовалась, просто как excel-евская таблица (ни нормализации, ни индексов - ничего, еще и с опечатками) с соответствующей производительностью. И несколько минут работы абсолютно среднего SQL-щика освободили очень много ресурсов. | | |
| 11
- 03.11.2016 - 12:29
|
2harsh. Да не только в этом проблема. Вообще, подход - детство. Если батарейка raid подходит к концу - со включенным writeback (если данные важны) этот сервер нельзя эксплуатировать. Выключаете writeback - и либо все и так нормально, либо деньги быстро найдутся. Место заканчивается - согласовываете с руководством квоты, каждое повышение квоты - служебка с намеком на деньги. Вы описываете какую-то дикую модель из 90-х, где админ - непонятное чудило из-под лестницы, вечно требующий деньги непонятно на что. Просто нужно ставить руководство в известность, что сколько стоит, и делать это заранее и непрерывно. | | |
| 12
- 03.11.2016 - 12:41
|
"согласовываете с руководством", точка. Инфантильный мальчик. Если вам не понятно о чем, гуляйте мимо. Помозгуйте между делом про MTBF. | | |
| 13
- 03.11.2016 - 16:29
| Цитата:
| | |
| 14
- 03.11.2016 - 16:44
|
2krotov. А дальше - ничего. Ну, разве что, делать это регулярно, с графиками(например - свободного места) и сроками исправления. И так, чтобы можно было поднять переписку, когда все взорвется. Я не могу из куска кремния напильником выпилить дополнительную память или жесткий диск. | | |
| 15
- 03.11.2016 - 16:57
|
Для тех у кого проблемы с концентрацией, вынужден процитировать самого себя Цитата:
| | |
| 16
- 03.11.2016 - 17:11
| Подчеркиваю инженеров, не шлюх, заглядывающих в рот пуководству на каждый чих. | | |
| 17
- 03.11.2016 - 17:12
| Цитата:
Вариант 1 (как ДДМ): - превентивно разбираем ситуацию, пытаемся донести до инженеров/руководства клиентов, своего руководства, у кого как, вероятных результатов наложения болта на проблему и в зависимости от решения оных: a) кладём (подложившись перепиской), когда крякнет, тогда и суетится пора пришла. b) что-то предпринимаем Вариант 2: долбаем и долбаем инженеров/руководство клиентов, своё руководство до белого каления, перелезая через головы всяческих менеджеров пока либо: a) не добьешься результата для принятия превентивных мер b) когда крякнет, и суетиться пора уже пришла. Отредактировано krotov; 03.11.2016 в 17:13. Причина: слова забыл | | |
| 18
- 03.11.2016 - 17:16
| 17+ тут зависит либо от отношения к клиенту, либо от важности клиента для компании. Далеко не всегда можно подложиться перепиской, точнее далеко не всегда это подкладывание поможет. | | |
| 19
- 03.11.2016 - 18:19
|
Мне по душе когда инженер что-то делает, сам. А не убивается в истерике, пытаясь до кого-то что-то донести) | | |
| 20
- 03.11.2016 - 19:59
|
2krotov. А ты единственный, кому это надо? Практика показывает, что если ты будешь водить вокруг всех хороводы и уговаривать - это просто станет твоей обязанностью и головной болью. И ответственностью. Я как-то пришел к тому, что нужно залогированная переписка, плюс - максимум один факап (а по факту, у каждого он уже был в прошлом, хотя тут кроется еще один момент: если ты оповещаешь какое-нибудь дерево - включи в копию его руководство). | | |
| 21
- 03.11.2016 - 20:02
|
2harsh. А что вы можете сделать сам? Батарейку для raid-контроллера спаять? Или за свои деньги купить? Я думал, что все, что зависит от вас, вы уже сделали. Или тема "я накосячил, вот думаю, исправлять или нет"? | | |
| 22
- 03.11.2016 - 20:57
|
Действительно, если просматривается некий кирдык, в предсказуемый период, то любой адекватный человек, не важно инженер он или дворник, превентивно разбирает ситуацию и что-то предпринимает. Если это не так, значит он просто раздолбай и бестолочь. | | |
| 23
- 03.11.2016 - 22:17
|
мне, просто, не нравится "просматривается некий кирдык". Попахивает шаманством. Мне больше нравится "я сделал все от меня зависящее, чтобы выявить все возможные кирдыки, оценить их, отсортировать по срочности и составить график исправления, а для тех, которые посчитали неисправимыми, по-хорошему - составить дизастер рекавери план" | | |
| 25
- 03.11.2016 - 23:09
|
дело не в "жопоотводе" (как мы это называли в Тандере). Дело во внутреннем чувстве перфекционизма. | | |
| 28
- 07.11.2016 - 00:24
| Цитата:
Не уповая на "авось ещё проработает". В моём опыте (50-60 клиентов, средний размер - 20-30 компьютеров, 2-4 сервера) есть те, у кого сервер работает уже 8-10 лет, а есть те, у кого через 5.5 либо начал феерически тормозить, либо просто мать умерла. И если фирма не может себе позволить остановку бизнес-процесса, серверы надо менять на новые по достижению ими возраста 5-6 лет | | |
| 29
- 07.11.2016 - 00:43
|
2StepanRazin. Имхо, ни на чем не основанное утверждение. Точнее, основанное на "шаманстве". В моей практике, были и 10-летние серваки, которые прекрасно работали, и новенькие HP-шные сервера, которые сразу лагали, и 1-летние IBM-овские лезвия, которые вдруг перестали загружаться и еще много чего. Имхо, сервера стоит заменять на рубеже 5-7 лет из следующих соображений: - Стоимость поддержки (если они на поддержке) - Соотношение производительность\потребляемое электричество или производительность\место в стойке(охлаждение, прочая инфраструктура ЦОД). Это скорее актуально для больших ЦОД. - Соотношение производительность\стоимость лицензий А если компания не может себе позволить остановку бизнес-процесса - нужно не сервера менять, а подходить к процессу системно. Например, виртуализировать все и иметь свободные ресурсы для выхода из строя N серверов, еще лучше - репликация на удаленную площадку, может быть - в облако. Возможно - нужен ЗИП. А вообще, нужен дизастер рекавери план. | | |
| 31
- 07.11.2016 - 21:26
|
29-Добрых дел мастер > экивоки на "шаманство" это приговор квалификации. ЖЫрная точка. | | |
| 32
- 08.11.2016 - 22:21
|
Ну если прям крякнет - конечно сразу решить надо, как по другому? А если на костыле походит до лучших времён, то и пусть) | |
Интернет-форум Краснодарского края и Краснодара |
