Парни, вам так хочется на одного дядю работать?

просто бывают "срочные контракты".

Вам родина дала интересную работу

где ты точно съебнешь через год два.

Вот так и надо

Я не понимал раньше

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

Тратил время по сути

а для этого нужна дока.

Все так

Че сидеть?

Я не жалею. Я примерно так и говорил. "Я не хочу заниматься хуйнёй, но если начальство прикажет - и хуйню я тоже сделаю. Пару раз. а на третий - уволюсь."

Но вообще если все сделано по уму

И по бп

Я видел несколько раз системы

И по бп

чьему бп ?

Где все было настроено как по учебнику

они же свои в каждой конторе

Это круто

они же свои в каждой конторе

Я Винду админил раньше

Там не особо то

ааа...

они же свои в каждой конторе

Нет

Нет

да.

поднимем уровень дискуссии.

Да и в линуксе много обще принятых моментов

Меня вот начальник прессовал за нестандартный порт ссш даже

документация она же нужна не на линукс а на систему которая получилась. в доке не стоит писать как перезапускать сервис через systemd

поднимем уровень дискуссии.

Я работал в конторе где техдир объездил полмира, работая в гигантах - лидерах индустрии и у него всё было изначально правильно, но он боялся комстроки а до меня у него на "фрилансе" работали довольно крутые 0дмины нашего городка, но "банковские", которые не могут в разработку, могут только в тётечек и опердень. И никто не прижился. А я был челом с улицы, без рекомендаций. И у нас всё взлетело.

имя, спасибо за рефлексию. она слегка офтопик.

имя, спасибо за рефлексию. она слегка офтопик.

Она очень чётко в различие между девопс и опс. Я использовал разработчецкие инструменты, 0дмины - такой "многомиллиардный банковский 1С". Я строил инфраструктуру, зависящую от качества кода, они - от личности человека. Качество кода - объективное понятие, личность - ...

Посмотри на тестовые задания наших и буржуев. Буржуи дают README.md или README.rst

Наши просят написать сочинение ("Нет, код не нужен!") по литературе, раскрывающее тебя как личность. Это неправильно, избегай этого подхода. Хорошая документация - это та, которая содержит примеры с кодом, идеальная - та, которая и есть код.

Наши просят написать сочинение ("Нет, код не нужен!") по литературе, раскрывающее тебя как личность. Это неправильно, избегай этого подхода. Хорошая документация - это та, которая содержит примеры с кодом, идеальная - та, которая и есть код.

с кодом есть проблнма - он не дает понимания оверолл пикча и кейсов

с кодом есть проблнма - он не дает понимания оверолл пикча и кейсов

overall picture - bugtracker - openproject (redmine), jira

о нет. Если overall picture - это багтрекер или редмайн, то это тупик.

overall picture - bugtracker - openproject (redmine), jira

багтрекер не даст картинки, опенпроджект это все таки немного не то, джира не знаю, редмайн - вики что ли?

кейсы оттуда же выносятся в документацию т.е. если кейсов более одного - создаём "родителя", цепляем, пояснения выносим в вики

о нет. Если overall picture - это багтрекер или редмайн, то это тупик.

вот да

редмайн это типа джиры только заббикс.

overall picture - ֿэто понимание бизнес процессов, это понимание зачем ты делаешь, то, что ты делаешь, кому от этого становится лучше и зачем твоя работа кому-то нужна.

overall picture - ֿэто понимание бизнес процессов, это понимание зачем ты делаешь, то, что ты делаешь, кому от этого становится лучше и зачем твоя работа кому-то нужна.

именно так. и собственно косвенно именно это чпрашивает Алексей

overall picture - ֿэто понимание бизнес процессов, это понимание зачем ты делаешь, то, что ты делаешь, кому от этого становится лучше и зачем твоя работа кому-то нужна.

диаграммы ганта dashboard-ы (канбаны и вот это вот всё)

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

диаграммы ганта dashboard-ы (канбаны и вот это вот всё)

это вообще каким местом?

если в тикете написана редкая поебень, делать тоже будем, потому что написали? или все-таки сначала выясним зачем это надо? :)

да не диаграммы и не тулзы.

люди, живое с ними общение.

так вот коллеги раз тут появились люди которые не только навязывают мнение но и возможно понимают что я хочу :) Как структурировать документацию ?

или “живое”, в цифровом пространстве, но не ק-צשןךи не тикет.

упс.. не e-mail и нет тикет

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

потом долго и упорно разребать нужно за такими целеустремлёнными "гениями" и дорого

это вообще каким местом?

overall picture общ. единая картина рекл. общая картина; общий вид JIRA

> так вот коллеги раз тут появились люди которые не только навязывают мнение но и возможно понимают что я хочу :) Как структурировать документацию ? Я всегда прошу всех документировать принципы, а не имплементацию. Документация конкретной имплементации устареет к момемту завершения ее написания. Если описать концепт, идею, причины решения проблемы и общее направление реализации отвязаное от кода или конкретного сервера - как по мне это самое главное. Документировать не как, а что и зачем.

это как раз понятно.

пока доку писали оно хоп и поменялось

а что непонятно? сорри, я влез в середине разговора сильно наверх не скролля :)

не понятно структурирование

мм рисовать деплоймент диаграммы ?

по серисам ? по базам ? по триггерам ?

если в тикете написана редкая поебень, делать тоже будем, потому что написали? или все-таки сначала выясним зачем это надо? :)

Это рабочий момент. Уточнение, конкретизация, "заворачивание". Главное - сохранить в письменном виде для истории, независимо от того - кто был прав. На суд истории, так сказать.

так вот коллеги раз тут появились люди которые не только навязывают мнение но и возможно понимают что я хочу :) Как структурировать документацию ?

Ну я тебе сослался на бабушку Немет. Я думаю это немного обучалка инструментам, потом овералл пикча в схемах и двухсловах, по ом прямо главы по кейсам. "Инвентори и его генерация", "Созжание бэкапов", "Добавление удаление хостов", "Организация доступа"

сопроводиловка в формате как решать триггеры или как оно устроено ?

Оверол по трекеру

по серисам ? по базам ? по триггерам ?

Сорри, я пропускаю контекст все-таки. Есть какая-то конкретная задача, которую надо документировать? Или ты в общем?

Это как из букв ж о п а собрать слово вечность

(пошел скроллить таки)

люди, живое с ними общение.

Это до четырёх человек. При пяти нужно писать внятные коммит-мессаджи с номером бага. во всяком случае в ИНДУСТРИИ разработки ПО - именно так.

Сорри, я пропускаю контекст все-таки. Есть какая-то конкретная задача, которую надо документировать? Или ты в общем?

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

Это до четырёх человек. При пяти нужно писать внятные коммит-мессаджи с номером бага. во всяком случае в ИНДУСТРИИ разработки ПО - именно так.

Вы не видели проекты где эти четверо менялись по пять раз

А иногда и все разом

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

Это общая и большая беда

так вот коллеги раз тут появились люди которые не только навязывают мнение но и возможно понимают что я хочу :) Как структурировать документацию ?

Алексей, я тебе ничего не продаю. Я просто пишу о том, что можно нагуглить колесо, которое ездит тысячи лет и ездит быстро. Разными словами, постоянно перефразируя. И не толко (не столько) для тебя. Тут же не только ты ЧИТАЕШЬ.

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

какая целевая аудитория этой сопроводиловки?

другая контора.

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

ответ засчитан, вопрос был поставлен неправильно :) Технари, пользователи, люди… понял.

ну эксплуатационщики в подразделении в котором у меня нет власти что то навязать. :)

я бы начал с описания системы в целом, глава первая, продажная. “зачем мы построили то, что построили, и какие задачи мы решаем”. Потом перешел бы к “каждодневные геморроидальные отростки и как их удалять”. А дальше уже по желанию. Какие есть ручки, кнопки и переключатели, зачем они придуманы и как влияют на поведение системы, и т.д.

> так вот коллеги раз тут появились люди которые не только навязывают мнение но и возможно понимают что я хочу :) Как структурировать документацию ? Я всегда прошу всех документировать принципы, а не имплементацию. Документация конкретной имплементации устареет к момемту завершения ее написания. Если описать концепт, идею, причины решения проблемы и общее направление реализации отвязаное от кода или конкретного сервера - как по мне это самое главное. Документировать не как, а что и зачем.

+1 Я просто уточняю, что ПРИНЦИПЫ УЖЕ документированы. И если подходов несколько - достаточно указать - каким пользовался архитектор. Т.е. "мы используем CamelCase", а не "прочитайте пожалуйста доку по именованию переменных методом Алексея Широких - она вам пригодится всё время работы в компании"

Документацию никто нахрен не читает. Если первая глава рассказыват о том, что сделано и зачем, а не как - это уже должно вызвать здоровый интерес. Писать troubleshooting guide, кстати тоже вариант, если надо просто дать кастомеру книгу с заголовком “если ты, мудак, сломал, или не дай Б-г оно само - смотри сюда”