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

Если ты реальный админ, ты должен уметь пользоваться (или хотя бы быстро ориентироваться и уметь читать документацию) ВСЕМ, а не одним только systemd.

Давай я позволю себе некоторую отвлеченную метафору, что бы мы могли лучше разобраться. В гражданской авиации каждый лётчик должен уметь управлять пассажирским лайнером в direct modе и решать разные нестандартные ситуации, такие случаи были широко описаны в литературе и заложены в программы тренажёров, например посадка без тяги, разнообразнейшие отказы авионики и т.д. Но на практике это почти никогда не приходится делать, поскольку авиалайнер оснащён кучей автоматизирующих все интеллектуальных систем, таких как автопилоты, навигация, ALS и т.д значительно упрощающих жизнь пилота, спокойствие пассажиров и авиакомпании.

Возвращаясь к управлению инфраструктурой, systemd это стандартизированная система для управления много чем, это не только запускалка сервисов, это важно понимать. Этот инструмент согласутся с другими системами управления и в реальной жизни все работают с этим, как бы это не задевало разных бородатых хиппи и ортодоксальных ненавистников корпораций, трясущихся с дырявым синкпэдом на фоне бабушкиного ковра.

Подобно тому, как никто не позволит тебе управлять самолётом в direct mode просто потому что тебе «захотелось и ты это умеешь», так и в реальной жизни тебе никто не позволит использовать какие-то свои костыли на баше и принос в прод какого-либо другого маргинального говна, если есть стандартный интерфейс управления. ИРЛ, всё происходит иначе: ты хочешь что-то поправить или залимитить, будь добр использовать тот подход, что имеется, когда ты взял ansible, что-то поменял в конфигурации юнита, закоммитил изменения и это после коммита уехало на автотесты и если все ок, система дёрнула ручку в AWX/Tower и изменённая конфигурация поехала на много-много машин, при этом внутри AWX/Tower ещё может быть напилина куча логики, автоматически отрабатывающей при изменении тобой определённых вещей.

Если ты реальный админ, ты должен уметь пользоваться (или хотя бы быстро ориентироваться и уметь читать документацию) ВСЕМ, а не одним только systemd.

Давай я позволю себе некоторую отвлеченную метафору, что бы мы могли лучше разобраться. В гражданской авиации каждый лётчик должен уметь управлять пассажирским лайнером в direct modе и решать разные нестандартные ситуации, такие случаи были широко описаны в литературе и заложены в программы тренажёров, например посадка без тяги, разнообразнейшие отказы авионики и т.д. Но на практике это почти никогда не приходится делать, поскольку авиалайнер оснащён кучей автоматизирующих все интеллектуальных систем, таких как автопилоты, навигация, ALS и т.д значительно упрощающих жизнь пилота, спокойствие пассажиров и авиакомпании.

Возвращаясь к управлению инфраструктурой, systemd это стандартизированная система для управления много чем, это не только запускалка сервисов, это важно понимать. Этот инструмент согласутся с другими системами управления и в реальной жизни все работают с этим, как бы это не задевало разных бородатых хиппи и ортодоксальных ненавистников корпораций, трясущихся с дырявым синкпэдом на фоне бабушкиного ковра.

Подобно тому, как никто не позволит тебе управлять самолётом в direct mode просто потому что тебе «захотелось и ты это умеешь», так и в реальной жизни тебе никто не позволит использовать какие-то свои костыли на баше и принос в прод какого-либо другого маргинального говна, если есть стандартный интерфейс управления. ИРЛ, всё происходит иначе: ты хочешь что-то поправить или залимитить, будь добр использовать тот подход, что имеется, когда ты взял ansible, что-то поменял в конфигурации юнита, закоммитил изменения и это после коммита уехало на автотесты и если все ок, система дёрнула ручку в AWS/Tower и изменённая конфигурация поехала на много-много машин, при этом внутри AWS/Tower ещё может быть напилина куча логики, автоматически отрабатывающей при изменении тобой определённых вещей.