плохо масштабируется при приеме на работу новых людей :(

screencast + video того, что руками делаешь обязательно с субтитрами и транскриптом

screencast + video того, что руками делаешь обязательно с субтитрами и транскриптом

плохо работает, синергия такой команды минимальна

это превращается в курсы повышения квалификации ))

вы опять всё смешали в кучу

нет ты ! )

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

надо делить на возомжность личного общения.

дял меня команда это ту пицца пати

ну и что вот этот новый человек пойдет и поймет сходу что у тя nginx патченный ?

смотря как патченный если правильно пропатчишь - поймёт

надо делить на частоту смены соррудников и приема новых людей

и на длительность проекта.

надо делить на частоту смены соррудников и приема новых людей

1 сострудник в полгода ротируется

и на длительность проекта.

2-3года.

я видел команды в которых не ротируются 9 лет уже.

мамонты !

проект в котором сейчас участвую на год.

чуваков всех не видел :)

ты за диски поясни лучше )

полезнее будет )

у тя там картинка которая будто бы всё объясняет :)

совсем наоборот

но без контекста так себе :)

заменили HDD на SHDD

ну и что вот этот новый человек пойдет и поймет сходу что у тя nginx патченный ?

➜ root@localhost ~ /usr/sbin/nginx -v nginx version: nginx/1.10.1 patched C#9023888

и что обновлять штатным обновлением его нельзя ?

Должны быть собраны пакеты и подняты репы. Иначе у тебя админ уйдёт в отпуск, поломаются 189 серверов из 500, биржа рухнет, акционеры найдут тебя и застрелят.

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

структура есть, называется message-id

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

поиск в реквест-трекере конкретного сервака, поиск в CMDB, поиск в вики (всё равно, что поиск в конфиге), если ничего не нашлось, ты полез и поломал сервер значит архитектура неудачная в идеале - это прям в мониторинге должно быть видно что ИМЕННО ЭТОТ фэйловер - особенный

это превращается в курсы повышения квалификации ))

иначе язык сотрёшь повторять одно и то же потом в онбординге: -кино обучающее посмотрел? -понравилось? -раз хуйня - записывай обновление

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

3000 человек, 150 офисов

поиск в реквест-трекере конкретного сервака, поиск в CMDB, поиск в вики (всё равно, что поиск в конфиге), если ничего не нашлось, ты полез и поломал сервер значит архитектура неудачная в идеале - это прям в мониторинге должно быть видно что ИМЕННО ЭТОТ фэйловер - особенный

как это должно быть задокументированно на ваш взгляд ?

как это должно быть задокументированно на ваш взгляд ?

CMDB API

RackTables+Icinga

Sounds good

CMDB API

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

эта особенность срабатывает в очень частном случае.

Вот кстати мы например пишем их в паппете рядом с манифестом

В README.md

возможно множество вариантов инсталяции без этого кейса

«в паппете» в смысле в репозитории с конь фигами

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

Деплой сервера не считается законченым, пока он не добавлен в КЕБД и мониторинг конфиг должен быть параметризуемым - замена или добавление ноды и т.д.

«в паппете» в смысле в репозитории с конь фигами

GUI?

Нет, зачем

Деплой сервера не считается законченым, пока он не добавлен в КЕБД и мониторинг конфиг должен быть параметризуемым - замена или добавление ноды и т.д.

вы специально игнорируете ?

Все админы, все в консоли :)

вот у нас есть параметр в конфиге, он как бы всем известный старый и обычный

но в одном конкретном кейсе он вызывает проблемы.

Открыл вимом и читай

причем в другой системе.

причем в другой системе.

Проблемы ==> фиксация (тикет открыть) решение == изменение: в плэйбук добавить тест: # capacity planing if RAM < 512G then .. if ramconfig successful then racktables.local/$SERVERNAME.current/RAM/modify/RAM.value=RAM.current

вы специально чтоли ? )

Давайте тогда ближе к телу.

если некая система хранящая данные. есть вторая система процессящая данные есть 3я система скрещивающая 2 этих. из за конкретных настроек первой системы, форсится ряд настроек в системе 3, в результате система 2 имеет очень странные сайд эффекты аля "медленно все работает" или "фризится"

как и где это должно быть зафиксированно, чтобы все все узнали ?

если некая система хранящая данные. есть вторая система процессящая данные есть 3я система скрещивающая 2 этих. из за конкретных настроек первой системы, форсится ряд настроек в системе 3, в результате система 2 имеет очень странные сайд эффекты аля "медленно все работает" или "фризится"

и вам нужно конфиг изменить под проблему по типу badram-патчей для ядра?

как и где это должно быть зафиксированно, чтобы все все узнали ?

в тикете

нам нужно изменить конфиг в системах 1 или 3, но проблему обнарживает система 2

в тикете

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

нам нужно изменить конфиг в системах 1 или 3, но проблему обнарживает система 2

пост мортем задача-то какая? чтобы конфиг не меняли? зделай так, чтобы его невозможно было изменить

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

пост мортем задача-то какая? чтобы конфиг не меняли? зделай так, чтобы его невозможно было изменить

задача чтобы знали про такое поведение те, кто будет использовать систему 2, и что оно возможно только если системы 1 и 3 настроены опредленным образом.

чтобы знали как менять - добавь проверку (тест) существования проблемы на системе от которой зависит текущая

if server_nastraival_ebanko == true then goto _nihuya_ne_vydet and exit

она к ней не имеет никакого отношения

у тебя есть люди которые пишут код(2), и работают через либы с системой 3, а проблема в том что в конкретном вариант их использования срабатывает поведение между 1-3

if vezde_vsyo_okey = true then else goto _nihuya_ne_vydet and exit

у тебя есть люди которые пишут код(2), и работают через либы с системой 3, а проблема в том что в конкретном вариант их использования срабатывает поведение между 1-3

кто-то из серваков печальный и навивает грусть-тоску?

никто

ERROR: S client not available

у тебя код фризится

у тебя код фризится

подожди, стой я увидел слово код!

О НЕТ ТОЛЬКО НЕ КОД

я его давно уже сказал, жаль что ты тока щас увидел

1) код откатывается 2) уведомление с важностью "срочная" сыпется на автора (комиттера) 3) через пять минут открывается чатик между ним и его тимлидом/менеджером

не погоди.

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

как зафиксировать эти знания в 3х абсолюно разных тимах

код пишет 1 тима, эксплуатирует хранение вторая, интеграцию 3я

4) ещё через минуту в чатик автоматически от имени тимлида вставляется обращение, адресованное комиттеру: "ты чё блядь, охуел?!"

код пишет 1 тима, эксплуатирует хранение вторая, интеграцию 3я

Это называется CI

и даже если тима 3 знает про такое поведение, как уберечь чтобы тимы 1-2 не поменяли настройки которые поломают все 3й

Фиксация знаний между отделами это грустно, да

и даже если тима 3 знает про такое поведение, как уберечь чтобы тимы 1-2 не поменяли настройки которые поломают все 3й

"ты чё блядь, охуел?!"

В среднем решается общением

Вот тупо общением между людьми.

и даже если тима 3 знает про такое поведение, как уберечь чтобы тимы 1-2 не поменяли настройки которые поломают все 3й

У тебя код ОПЯТЬ ФРИЗИТСЯ!!!!111

Но это только в сравнительно малых масштабах

пошла невмененка )

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

и тикеты завдить

но в жизни проблемы другие какие то

и никакие вики и тикеты не помогают

Но это только в сравнительно малых масштабах

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

а помогает прийти к коллеге из другой тимы и сесть разбираться

В жизни люди как-то умудряются тупо спросить.

В жизни люди как-то умудряются тупо спросить.

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

Ну не, в рибми и вики тоже хорошо

но в жизни проблемы другие какие то

это та же самая проблема: 1) нет (или поломана) интеграция между сервисами 2) кто-то сделал код, ломающий что-то

Просто нужны люди, чтобы направить куда ндао

эт конечно

Мы даже с бывшими коллегами общаемся вот