group-telegram.com/interface31/4248
Last Update:
Что такое хорошо и что такое плохо
В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации.
В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту.
Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.
Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо.
Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны.
Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны.
Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.
Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались.
Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее:
- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…
Или:
- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…
Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы.
Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту.
Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами.
И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора».
И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.
Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно.
Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.
Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами.
Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо.
При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто.
Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз.
Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.
BY Записки IT специалиста
Share with your friend now:
group-telegram.com/interface31/4248