ты ему сервер он тебе доку. поставлены такие то пакеты, с момента установки сервера обновлены такие то файлы в диреткории etc

etckeeper

ты ему сервер он тебе доку. поставлены такие то пакеты, с момента установки сервера обновлены такие то файлы в диреткории etc

хехе, вы руками сервера сетапите? экспуатировать такое будет тяжко, да )

нее не руками

ансиблом всё

etckeeper

➜ root@localhost ~ ➜ root@localhost ~ cd /etc ➜ root@localhost /etc git:(master) git status # On branch master nothing to commit, working directory clean ➜ root@localhost /etc git:(master)

просто я не верю что бывают плейбуки которые с бареметал делают сервер. мой чертовски близок... но все равно далёк.

ну тогда зачем что то на сервере инспектить? можно если надо из ансибла того же генерировать

но ок, послушаем у кого есть что сказать

ну тогда зачем что то на сервере инспектить? можно если надо из ансибла того же генерировать

генерировать из ансибла что ?

> ты ему сервер он тебе доку. поставлены такие то пакеты, с момента установки сервера обновлены такие то файлы в диреткории etc ты ему ямл файлики, а он тебе вот это

Андрей, у вас так много серверов что на 98% вы никогда не были по ssh ?

один фиг во время любой эксплуатации копятся файлы настройки и прочая фигня которая со временем имеет свойство накапливаться.

и в результате сервера идентично настроены ансиблом. но тут вот sysctl поправлен.

сейчас у меня вообще продакшена нет :) но высокая степень автоматизации и иммутабельность виртуалок приводит к тому, что ноды часто меняются ;)

Андрей, у вас так много серверов что на 98% вы никогда не были по ssh ?

У меня 777 рабочих станций только в папете

и в результате сервера идентично настроены ансиблом. но тут вот sysctl поправлен.

я б за такое по рукам въебал и все ;)

а на этом пасять сгорела и вместо 256G стоит 192G это слегка сказалось на настройках

и в результате городятся какие то исключения.

ну лично мне кажется, что вы сами себе создали проблему, а теперь пытаетесь не решить ее, а сверху замок построить

и в результате сервера идентично настроены ансиблом. но тут вот sysctl поправлен.

Его будет видно в etckeeper 'daily autocommit' (git log)

ну лично мне кажется, что вы сами себе создали проблему, а теперь пытаетесь не решить ее, а сверху замок построить

а как надо ?

я б за такое по рукам въебал и все ;)

etckeeper —> autocommit —> remote —> hook —> hotfix branch —> alert comitter (mattermost, sms)

Его будет видно в etckeeper 'daily autocommit' (git log)

принципиально мне не нравится идея что /etc лежит в гите. это создает фальшивую уверенность.

мне не нравится и идея того что сервера со временем перестают быть идентичными

а как надо ?

никаких настроек руками, просто забыть об этом. ну или вон вам подсказывают, что можно хотя бы логировать и документировать изменения через гит

никаких настроек руками, просто забыть об этом. ну или вон вам подсказывают, что можно хотя бы логировать и документировать изменения через гит

ок. супер. пример с сервером у которого по причине инвалидности стало меньше памяти ?

ну если уж так дорого ему память чинить — делать спешиал кейс в конфигах

и в результате городятся какие то исключения.

Это не "исключение", это повод заточить плэйбуки: 1) параметризовать 2) добавить тестов всё автоматизируемо!

вы все праивльно говорите.

и я бы тоже самое сейчас говорил.

и в плейбуке для расчета sysctl у меня формулы.

но это не дока же.

мне не нравится и идея того что сервера со временем перестают быть идентичными

Для этого используем дифференциальный анализ файловых систем etckeeper - простейший инструмент, секьюрнет я вам не советую ? и эншуры (puppet ensure, забыл как аналог в ансамбле называется)

точнее это не та дока которую можно кому то сдать.

я вот etckeeper сейчас на ноутбук поставлю

он там хорошо и праивльно ляжет

а в проде я почему то хочу не так.

Для этого используем дифференциальный анализ файловых систем etckeeper - простейший инструмент, секьюрнет я вам не советую ? и эншуры (puppet ensure, забыл как аналог в ансамбле называется)

для проверки работы сервера есть goss

но это тоже не дока.

но это не дока же.

Если 0дмин руками правит файл и не документирует это заранее обговоренным способом (commit message —> changlog —> дока по эксплуатации) - гоните его, всё равно у вас всё рухнет если/когда его собъёт машина.

commit template

ладно это была скучная часть. инструментальная.

а что с интерсной частью ? методикой документирования ?

как понять что документация достаточна ?

что должно быть написано в документации ?

Если 0дмин руками правит файл и не документирует это заранее обговоренным способом (commit message —> changlog —> дока по эксплуатации) - гоните его, всё равно у вас всё рухнет если/когда его собъёт машина.

У нас в своё время новому сетевику дали ноут, дали кабель и пароль для ближайшего роутера. Сказав, что старый сетевик считай что умер.

в интернеах я помню был тест лимончелли и его примером по тому как надо вести доку

https://docs.google.com/document/pub?id=1r2-0CH-ZnCjzyl214JRu4jYr25HHNPGoRtE5QQlDe1M#h.reo6xpjp5h0j

вот это вот

может есть еще какие то подходы ?

что должно быть написано в документации ?

1) у вас УЖЕ есть дока по эксплуатации от авторов - велосипед с круглыми колёсами 2) вы пишите комментарии к патчу (diff-у) конфига —> commit message

imya это похоже на правду. но это лишь что делано.

а есть еще дока по работе во время сбоя

перенос сервиса на другой сервер

отработка триггеров

и прочее

методички, хаутушки

то что можно делегировать на дежурную смену сняв с админа

да сейчас оглядывая хозяйство даже смешные вещи типа реглмента по перезапуску сервиса

а есть еще дока по работе во время сбоя

1) Какой вывод и какой команды достаточен для того, чтобы доказать, что проблема вне зоны ответственности команды. 2) В каком порядке инцидент обходит команды

imya я немного о другом.

1) Какой вывод и какой команды достаточен для того, чтобы доказать, что проблема вне зоны ответственности команды. 2) В каком порядке инцидент обходит команды

т.е. "чем докажешь?"

дока по написани доки

такое вот хочу

перенос сервиса на другой сервер

diff/patch/commit message

то что можно делегировать на дежурную смену сняв с админа

это не эксплуатация, это

ERROR: S client not available

diff/patch/commit message

эм. сириос ?

Рисуй структурные схемы, схемы потоков данных, схемы процессов. Главное - расписать обязанности (зоны ответственности) и порядок обработки инцидентов (ITIL/ITSM)

<

видимо в комимт мессадже будет информация по отключению 3 сервисов там и перезапуску двух там. потом рестарту самого сервиса с новым конфигом.

и хранится будет не вики а тупо гит репа в которой будет сделан полнотекстовый поиск.

отличная идея. но это не то. я совсем не про это спрашиваю ведь.

видимо в комимт мессадже будет информация по отключению 3 сервисов там и перезапуску двух там. потом рестарту самого сервиса с новым конфигом.

Тебе нужно порядок уведомления, согласования и отчёта (пост-мортема в случае неудачи) - разбора полётов согласовывать. Если ты будешь вручную "по хаутушке" это (переезд сервера) делать - как 20 лет назад - тебе не в этот чат.

imya есть чо почитать ?

книги ?

статьи ?

книги ?

ITSM

видимо в комимт мессадже будет информация по отключению 3 сервисов там и перезапуску двух там. потом рестарту самого сервиса с новым конфигом.

Вероятность ошибки == 100%, даже при идеальной инструкции. Человеческий фактор - противоречие с принципом Инфрастуктура-как-код

еще раз. что бы сделать что то сложное надо сделать это через плейбук.

что бы знать какой плейбук запустить нужна дока.

в которой будет написано иди делай вот это.

в которой будет написано иди делай вот это.

"иди делай" == Вероятность ошибки 100%

я всё понял. спасибо. есть еще мнения ?

я всё понял. спасибо. есть еще мнения ?

Ты сейчас демонстрируешь подход построения идеальной инфраструктуры по идеальной документации. Идеально немасштабируемой и неподдерживаемой. 0дмины нужны для автоматизации, т.е. уменьшения затрат ФОТ. А ты - наоборот - создаёшь рабочие места: 1) человек, поддерживающий актуальность доков который на практике превращается в 2) человека, знающего, что в доках неправильно 3) человека, умеющего правильно

нет, я всего лишь стремлюсь сделать так что бы люди ходили в отпуска. и что бы люди которые назыаются девопс могли спокойно спасть когда надо решить мелкую проблему.

Вся документация должна быть в коде, на каждую строку конфига (stanza) - две строки: 1) что делает код 2) почему (зачем) он делает так

а еще что бю люди могли уходить и можно было нанимать новых людей.

если с помощью какого либо инструментария можно поддерживать документацию в более актуальном состоянии чем это делается через wiki + playbook это здорово. но речь не об этом же.

Вся документация должна быть в коде, на каждую строку конфига (stanza) - две строки: 1) что делает код 2) почему (зачем) он делает так

напрочь не понимаю как документирование конфигов соотносится с документацией по решению типичных косяков.

совсем не понимаю как документирование конфигов помогает дежурной смене устранять триггеры по скорому окончанию места в разделе

нет, я всего лишь стремлюсь сделать так что бы люди ходили в отпуска. и что бы люди которые назыаются девопс могли спокойно спасть когда надо решить мелкую проблему.

1) исключить участие человека, т.е. 0дмин ничего не должен делать руками всё через код код должен быть стандартным т.е. проходить через линт и не содержать антипаттернов (опенсорс или парное администрирование) в абсолюте - он не должен писать никаких скриптов и никаких команд не выполнять а брать готовые плейбуки и патчить их 2) все свои заклинания он должен расшифровывать описывая только отличия например, пусть откроет хистори и к непонятным командам сделает "алиасы" на русском языке - они и будут "документацией" а к частым - плэйбук для крона

как обовсем это узнает новый админ ?

а еще что бю люди могли уходить и можно было нанимать новых людей.

для этого у тебя всё должно быть стандартное а все отличия (зоопарк+говнокод) - подробно документированными

>- подробно документированными ну слава богу

какова методика документирования то ?

как обовсем это узнает новый админ ?

хистори распечатывается и сдаётся в первый отдел, безопаснику ?

Имя. я просто вынужден спросить.

когда ты последний раз что то админил ?

Имя. я просто вынужден спросить.

иди в церковь, поясни за диски )