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

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

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

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) все свои заклинания он должен расшифровывать описывая только отличия например, пусть откроет хистори и к непонятным командам сделает "алиасы" на русском языке - они и будут "документацией" а к частым - плэйбук для крона

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

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

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

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

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

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

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

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

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

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

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

Денис, сорян, не могу. тут _кто то не прав_.

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

1) на исправимый косяк делается ишью/багрепорт, в результате пост-мортема задача менеджеров - его подвинуть на более или менее отдалённую перспективу если на очень отдалённую - он там будет висеть вечно и передаваться новичку там же будет и "обходное решение" - workaround 2) на неисправимый пишется грусть-печаль-тоска-дока с заголовком типа "как распознать тот самый сервер, приносящий несчастья"

а wiki не? от hugo до dokuwiki

а wiki не? от hugo до dokuwiki

вики да. вики наше всё.

структура то в вики какая ?

не в кучу же все складывать

кстати забавно, но кроме докувики ничего простого нет

все вики отстой

структура то в вики какая ?

а это самое основное. тогоже Кернигана или бабушку Немет можно и нуно любить только за оглавления

Но wiki тем и хороша, что можно мгновенно поменять

Да, вики сосут

Да, вики сосут

ееее..... !

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

сегодня. уволен с комментарием: "ты слишком умный для нас! мы не погромизды! не заставляй нас писать код пожалуйста!"

Из всех, что я трогал, moinmoin был самой наименее сосущей

Из всех, что я трогал, moinmoin был самой наименее сосущей

эй эй. сосут не вики а реализации вик

а сами вики хороши.

вики тож

Из всех, что я трогал, moinmoin был самой наименее сосущей

громоздкое гавно. я его не асилил даже завести

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

commit message —> changelog —> дока по эксплуатации

вики тож

тех вик которые сосут мы обсуждаем в другом чатике.

commit message —> changelog —> дока по эксплуатации

так не работает

даже не знаю можно ли давать тут ссылку на него