Size: a a a

Обсуждения техдирские

2020 July 14

VM

Vladimir Myasnikov in Обсуждения техдирские
Artem Shpynov
мне кажется это вообще  не связанные вещи: "адекватный бизнес не понимает что делается в проекте" или "неадекватный бизнес не верит никому"
Согласен. На мой взгляд, политика максимальной открытости будет работать только в случае, когда стороны ещё готовы разговаривать.
источник

AP

Andrey P in Обсуждения техдирские
Dmitriy K
бизнесу лучше стало в итоге?
Аладдин Р.Д. капец.
источник

AS

Artem Shpynov in Обсуждения техдирские
Vladimir Myasnikov
Согласен. На мой взгляд, политика максимальной открытости будет работать только в случае, когда стороны ещё готовы разговаривать.
просто бывают ситуации когда неверит===не понимает. и тогда открытость прозрачность и все это вот. а если не верит === подозревает тут уже с открытостью не полечить
источник

AP

Andrey P in Обсуждения техдирские
Dmitriy K
какие выводы сделали? Пытались вернуть прежнюю команду?
Точка притяжение команды -  старший RnD менеджер. Нельзя вернуть команду отдельно.
источник

AS

Artem Shpynov in Обсуждения техдирские
Andrey P
Точка притяжение команды -  старший RnD менеджер. Нельзя вернуть команду отдельно.
можно, но сложно. особенно если адекватности в руководстве не просматривается
источник

AP

Andrey P in Обсуждения техдирские
Artem Shpynov
можно, но сложно. особенно если адекватности в руководстве не просматривается
Могут наоборот лить грязь на тех, кто работал ранее. Все были врагами и вредителями. Портили и крали код.
источник

PD

Phil Delgyado in Обсуждения техдирские
Ну, это же классический "первый конверт" )
источник

AP

Andrey P in Обсуждения техдирские
Phil Delgyado
Ну, это же классический "первый конверт" )
Ага, в исполнении собственника-CEO.
источник

PD

Phil Delgyado in Обсуждения техдирские
Ну, у собственника только одна проблема - ему третий конверт не поможет.
источник

AP

Andrey P in Обсуждения техдирские
Phil Delgyado
Ну, у собственника только одна проблема - ему третий конверт не поможет.
Да :)
источник

HB

Harry Box in Обсуждения техдирские
Andrey P
Могут наоборот лить грязь на тех, кто работал ранее. Все были врагами и вредителями. Портили и крали код.
Заметил, что такое очень модно в нашей стране. Если зовут на "освободившуюся" должность CTO достаточно спросить, куда делся предшественник, чтобы "началось". Собственно, так и детектят "токсичные" коллективы, но опытный HR может пресечь утечку информации и это уже из разговоров с коллективом придется узнавать.
источник

AP

Andrey P in Обсуждения техдирские
Harry Box
Заметил, что такое очень модно в нашей стране. Если зовут на "освободившуюся" должность CTO достаточно спросить, куда делся предшественник, чтобы "началось". Собственно, так и детектят "токсичные" коллективы, но опытный HR может пресечь утечку информации и это уже из разговоров с коллективом придется узнавать.
У меня было прикольнее. При глашал меня директор по продуктам. Я вышел на работу, а его нет. То ли уволился, то ли сожрали. Опытный HR директор скрыла.
источник

ТЕ

Таёжный Ежи... in Обсуждения техдирские
Andrey P
У меня было прикольнее. При глашал меня директор по продуктам. Я вышел на работу, а его нет. То ли уволился, то ли сожрали. Опытный HR директор скрыла.
Его отпустили с условием, что подберёт себе замену?
источник

AP

Andrey P in Обсуждения техдирские
Таёжный Ежи
Его отпустили с условием, что подберёт себе замену?
Он подбмрал себе peer, потому как старый техдир срывал все релизы и продуктовую стратегию нельзя было реализовать.
С 2018 старый техдир вернулся к управлению, кстати. Поэтому Jacarta-3 существует лишь в статьях CEO, но не в реальном мире :)
источник

AS

Artem Shpynov in Обсуждения техдирские
ну бывает чего... но иногда уход предшественника необходим так скажем :) но тогда сразу ичего хорошего не жди
источник

IB

Ivan Brotkin in Обсуждения техдирские
всем привет!

А поделитесь практиками, кто как описывает админам/девопсам требования к разворачиваемому ПО? У нас сейчас проблема (в отсутствие девопса как такового), что приходится админам описывать требования прям подробно, вплоть до конкретных команд в шелле (юзают ansible). При этом один хрен хромает мониторинг, сбор логов и тд, так как стандарта нет, а админы сами его придумывать не будут. В лучшем случае прикрутят стандартные метрики в заббикс/нагиос и ротацию текстовых логов.

Как я себе это вижу: мы прописываем прям стандарт (рецептом можно назвать) для каждого вида софта. Например, для nginx нужно брать конфиги проекта там-то в репозитории, логи писать в текст туда-то и еще отправлять в ELK, мониторинг через готовый шаблон заббикса, обновлять по таким-то правилам. И тд.

Это довольно долго и тоскливо собирать и вылизывать, но на выходе по идее должно сильно добавить прозрачности со всех сторон. В итоге проект будет как набор кубиков для админов - тупо собрать из готовых решений по стандарту. Начнем наверное с простых google docs, разбитых по приложениям, но может есть решения получше? В том числе интересует и дальнейшее сопровождение, так как эти стандарты, очевидно, не статические и должны меняться.
источник

AU

Aleksey Uchakin in Обсуждения техдирские
Ivan Brotkin
всем привет!

А поделитесь практиками, кто как описывает админам/девопсам требования к разворачиваемому ПО? У нас сейчас проблема (в отсутствие девопса как такового), что приходится админам описывать требования прям подробно, вплоть до конкретных команд в шелле (юзают ansible). При этом один хрен хромает мониторинг, сбор логов и тд, так как стандарта нет, а админы сами его придумывать не будут. В лучшем случае прикрутят стандартные метрики в заббикс/нагиос и ротацию текстовых логов.

Как я себе это вижу: мы прописываем прям стандарт (рецептом можно назвать) для каждого вида софта. Например, для nginx нужно брать конфиги проекта там-то в репозитории, логи писать в текст туда-то и еще отправлять в ELK, мониторинг через готовый шаблон заббикса, обновлять по таким-то правилам. И тд.

Это довольно долго и тоскливо собирать и вылизывать, но на выходе по идее должно сильно добавить прозрачности со всех сторон. В итоге проект будет как набор кубиков для админов - тупо собрать из готовых решений по стандарту. Начнем наверное с простых google docs, разбитых по приложениям, но может есть решения получше? В том числе интересует и дальнейшее сопровождение, так как эти стандарты, очевидно, не статические и должны меняться.
Если есть ансибл, то почему бы не вида
git pull
ansible-playbook -CD main.yml
ansible-playbook -D main.yml
источник

IB

Ivan Brotkin in Обсуждения техдирские
вопрос не в том, как применять сценарии. скорее в том, чтобы описывать требования с нашей стороны и выполнять их со стороны исполнителей
источник

IB

Ivan Brotkin in Обсуждения техдирские
и всю эту схему сопровождать
источник

IB

Ivan Brotkin in Обсуждения техдирские
по факту нам сейчас придется читать плейбук, чтобы понять, чего там админы наворотили
источник