История изменений

Только ты не контролируешь. Тебе кажется, что ты контролируешь.

Просто с пропатченными мозгами ты не можешь это представить. Нет, я контролирую. Используя доступные мне средства и соблюдая SLA. Когда-то была система контроля конфигов cfengine. Ее авторы, как и ты, были большими теоретиками. Писали про контракты и контролируемые состояния. Пользоваться было невозможно, слишком велики затраты. Потом появился ansible без всяких теорий. Админы быстро его освоили.

«Пингуется — и за*бись». А если кривые скрипты не запустят какой-то процесс...

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

systemd банально контролирует большее количество сущностей, чем скрипты

В том-то и дело. Полагаясь на systemd, ты забываешь, что никакой софт не может учитывать всего. Так было, когда systemd снес данные чьей-то базы в shm. Кастомные чеки работаю там, где критично, хотя и требуют отладки.

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

Как и со всяким языком, чем ниже порог вхождения, тем больше некачественного кода. Так, как с PHP, например. Но. Это не отменяет тот факт, что для более сложной логики мы берем python или любой другой подходящий инструмент. Если мы хотим спроектировать систему под наши требования, у нас есть гибкость. А ты хочешь действовать по твердой инструкции из MSDN и если произошло что-то непредвиденное, то ты огребешь в 10 раз больше проблем. Вместо простых действий по исправлению, ты будешь ребутать весь ДЦ. В Windows, как ты помнишь, все эти манагеры давно написаны именно в таком ключе. Вообще я думаю, что Microsoft way тебе по многим параметрам должен казаться близок.

Скрипты - это всего лишь клей. Кто-то все делает на клею. Я стараюсь намазывать тонким слоем между известными компонентами. Расширять возможности того же zabbix, например.

Соляровцы в отличных пропорциях используют комбинацию скриптов и манагера сервисов. А systemd - нет. Поттер нагромоздил уже выше крыши, решая все новые и новые возникающие перед ним юзкейсы, а в итоге мы всеравно в systemd ini будем вставлять строчку для выполнения в bash.

Только ты не контролируешь. Тебе кажется, что ты контролируешь.

Просто с пропатченными мозгами ты не можешь это представить. Нет, я контролирую. Используя доступные мне средства и соблюдая SLA. Когда-то была система контроля конфигов cfengine. Ее авторы, как и ты, были большими теоретиками. Писали про контракты и контролируемые состояния. Пользоваться было невозможно, слишком велики затраты. Потом появился ansible без всяких теорий. Админы быстро его освоили.

«Пингуется — и за*бись». А если кривые скрипты не запустят какой-то процесс...

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

systemd банально контролирует большее количество сущностей, чем скрипты

В том-то и дело. Полагаясь на systemd, ты забываешь, что никакой софт не может учитывать всего. Так было, когда systemd снес данные чьей-то базы в shm. Кастомные чеки работаю там, где критично, хотя и требуют отладки.

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

Как и со всяким языком, чем ниже порог вхождения, тем больше некачественного кода. Так, как с PHP, например. Но. Это не отменяет тот факт, что для более сложной логики мы берем python или любой другой подходящий инструмент. Если мы хотим спроектировать систему под наши требования, у нас есть гибкость. А ты хочешь действовать по твердой инструкции из MSDN и если произошло что-то непредвиденное, то ты огребешь в 10 раз больше проблем. Вместо простых действий по исправлению, ты будешь ребутать весь ДЦ. В Windows, как ты помнишь, все эти манагеры давно написаны именно в таком ключе. Вообще я думаю, что Microsoft way тебе по многим параметрам должен казаться близок.

Скрипты - это всего лишь клей. Кто-то все делает на клею. Я стараюсь намазывать тонким слоем между известными компонентами. Расширять возможности того же zabbix, например.

Только ты не контролируешь. Тебе кажется, что ты контролируешь.

Просто с пропатченными мозгами ты не можешь это представить. Нет, я контролирую. Используя доступные мне средства и соблюдая SLA. Когда-то была система контроля конфигов cfengine. Ее авторы, как и ты, были большими теоретиками. Писали про контракты и контролируемые состояния. Пользоваться было невозможно, слишком велики затраты. Потом появился ansible без всяких теорий. Админы быстро его освоили.

«Пингуется — и за*бись». А если кривые скрипты не запустят какой-то процесс...

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

systemd банально контролирует большее количество сущностей, чем скрипты

В том-то и дело. Полагаясь на systemd, ты забываешь, что никакой софт не может учитывать всего. Так было, когда systemd снес данные чьей-то базы в shm. Кастомные чеки работаю там, где критично, хотя и требуют отладки.

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

Как и со всяким языком, чем ниже порог вхождения, тем больше некачественного кода. Так, как с PHP, например. Но. Это не отменяет тот факт, что для более сложной логики мы берем python или любой другой подходящий инструмент. Если мы хотим спроектировать систему под наши требования, у нас есть гибкость. А ты хочешь действовать по твердой инструкции из MSDN и если произошло что-то непредвиденное, то ты огребешь в 10 раз больше проблем. Вместо простых действий по исправлению, ты будешь ребутать весь ДЦ. В Windows, как ты помнишь, все эти манагеры давно написаны именно в таком ключе. Вообще я думаю, что Microsoft way тебе по многим параметрам должен казаться близок.