Сисадмин: "секреты профессии которые вам не расскажут"
Ну или расскажут, я вот, например.
Я сисадмин.
Я тоже не знаю как делать эту хрень (но я умею пользоваться поиском).
Я делаю эти три команды на корневом роутере полтора часа не потому что смотрю сериал в процессе, а потому что сначала гуглю возможные последствия и хочу досканально понять что они делают и как повлияют на всё. Потому что пятая точка и большой опыт подсказывают мне, что я могу уронить большой кусок инфраструктуры, если я не предусмотрю чего-то. Хуже того, они же мне подсказывают, что я всегда могу не предусмотреть чего-то и всё равно йобнуть чего-нить (спасибо, что есть commit trial - штука которая всё откатывает если ты потерял контроль врезультате своих действий, но, к сожалению, есть она или её аналоги не везде).
И мне всегда ссыкотно делать большие изменения первый раз, но кто кроме меня то. Иногда зову коллегу и нам ссыкотно вдвоём. Но мы делаем.
Если мы делаем что-то в нерабочее время, значит вероятность большого пиздеца в инфраструктуре тоже большая, а не потому что нам нравится работать в ночь с субботы на воскресенье.
Иногда самая быстрая диагностика полного пиздеца - выключить всё и включать по одному большому куску. Локализовать кусок, выключить в нем всё и включать по одному устройству. Да, вот так топорно.
Довольно часто я не знаю, сработает ли эта конкретная штука/настройка или нет, потому что я не знаю всю систему наизусть (а документированы некоторые системы тоже.. так себе). Я примерно представляю, что хуже не станет, и просто делаю и смотрю что будет. И так несколько раз. Иногда смотрю разными интсрументами и снимаю лог. И делаю чуть по другому. И так раз за разом, пока не найдется решение или не будет достигнуто понимание, как оно работает. Это тоже часть работы.
Чем больше раз ты сделаешь предыдущий пункт, тем чаще сможешь быстро найти нужную комбинацию настроек, исходя из "чуйки", но на смом деле, это накопленный опыт понимания работы определенных систем.
Если мне звонят в отпуске и проблема не выглядит как "всё рухнуло и бизнес встал", я направлю к решению/документации устно и скажу, что не у компа, чтобы мои сотрудники и коллеги учились диагностировать и решать проблемы в моё отсутствие.
Если вы видите, что инструкция содержит очевидные пункты и написана как для дауна - не потому что я хочу над вами поиздеваться, а потому что кто-то до вас не нашел эти пункты очевидными, либо я предполагаю, что такие найдутся, исходя из жопочуйственного опыта. И всегда кто-то откроет новую грань прочтения инструкции.
Если у вас хороший интуитивно понятный интерфейс в клиенте софта, это не значит, что админка такая же удобная. Часто на админку кладут болт и делают по остаточному принципу. Не работающий копи-паст и не расставленные таб-индексы не редкость, а только вершина айсберга обычно. Страдаем, но жрем кактус ради пользователей. Потому что удобно должно быть не нам, а бизнесу.
В большой системе (компании), которая выросла сама собой в течение многих лет и стала работать круглосуточно нельзя всё сломать и сделать хорошо "как в лучших домах, по регламентам и itil". Вернее, можно попробовать создать рядом копию системы "хорошо" и туда переселить сотрудников, но это ОЧЕНЬ дорого и таких примеров я не знаю. Можно поэтапно улучшать разные куски и двигаться в более хорошую сторону так далеко, сколько ресурсов у компании есть. Всё.
Довольно часто невозможно принять наилучшее решение. Потому что у вас недостёт информации (о системе, о компании, просто опыта и т.д.). Я принимала плохие решения, последствия которых выплывали через много лет. И это нормально, решение продержалось 6 лет и тогда казалось оптимальным. Тот, кто оглядываясь назад не может сказать "я ошибался", тот не развивается. Обычно, лчучше принять какое-то решение, чем не принимать никакого.
