Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Руководитель команды разработки
Lead
People management
Project management
Java
DevOps
Linux
CI/CD
Software development
А сколько хостов в кластере ProxMox и сколько кластеров?
Помню, давно находил заметки на форуме, что 32 ноды это нормально, потолок Corosync 100 нод и без гарантий нормальной работы.
Не соглашусь - любой инструмент требует правильного применения.
Jenkins такой же инструмент, как и GitLab, упомянутый в другом комменте. Если вы посмотрите на раздел документации GitLab Security Hardening, то там тоже много пунктов что и как правильно стоит делать.
Если вернемся к итогам из статьи:
Следить за CVE и уязвимостями надо как в Jenkins, так и в GitLab (или любом другом продукте)
Делать отдельный инстанс для тестов обновлений - вариант нормы в любом продукте
Разграничивать CI/CD - тема для рассуждений "как правильно", бывают варианты
Подписывать артефакты тоже нужно - на gitlab схема supply chain attack также может быть применена. В зависимости от инсталляции и интеграции могут быть кейсы более или менее успешной атаки
Внешняя аутентификация - чаще всего ее делают в больших инсталляциях в любом случае, для удобства
Защита от CSRF и XSS - должна быть, возможно в GitLab, она просто включена из коробки
В GitLab через бездумное создание джоб также тоже много чего можно поделать
Еще хотел бы подсветить, что не совсем корректно сравнивать GitLab и Jenkins:
GitLab это комбайн, который умеет много чего (хранение код, сборка и т.д.)
Jenkins это специализированный инструмент под конкретный вид задач
Каждый имеет плюсы и минусы, разные концепции применения и реализации самого инструмента. Однозначного лидера, на мой взгляд нет.
Спасибо за развернутые комментарии и конструктивный диалог. Мы могли бы продолжить, но, кажется, наши рассуждения уже выходят за рамки комментариев Хабра и превращаются в "простыни".
Я уважаю вашу позицию, хотя и не до конца с ней согласен. Как и раньше, никого ни к чему не принуждаю - каждый читатель Хабра сам решит как ему поступать.
Работник подписывается под выполнение определенных задач, которые, по идее, должны быть отображены в его должностной инструкции. Формулировки в ДИ чаще всего довольно широкие и подразумевают разные трактовки. Обязанность о передаче результатов своих трудов описывается в трудовом договоре (или еще где-то, не помню точно).
Если вы здесь хотите подвести под идею "Не написано в ДИ - идите нафиг", то я отвечу так: на мой взгляд, исчерпывающей ДИ не может быть в природе (либо ее придется постоянно править). Это как с законом - описаны общие принципы, но нет детализации до винтика. Хорошо это или нет - спорный вопрос. Я бы перевел это больше в область доверия и соблюдения данных слов. Если вы о чем-то договорились и это соблюдается, то формальное оформление уходит на второй план.
Есть ли у такого доверия риски - безусловно есть. Мой подход больше основан на том, что если вы не держите слово, то мы вряд ли будем работать вместе дальше.
Соглашусь, что наличие ошибок возможно, но наличие критических ошибок на Проде говорит о некачественном процессе разработки, не обязательно виноват программист (мог накосячить QA). Тем не менее, я считаю, что исправлять крит ночью все равно надо, тем более, что кроме разработчика никто другой может эту часть не знать так же хорошо.
Да, есть такая история, что у разработчиков делают ненормированный график. Но на мой взгляд тут надо руководствоваться принципами разумности. Если у вас эта история ночного фикса раз в квартал, то может и не стоит "лезть в бутылку" и просто починить? А заодно провести ревью всего процесса и выработать меры по предотвращению этого в будущем?
Любой график позволит допускает перекосы, адекватной руководство и нормальные отношения кмк более важны, чем документально оформление режима работы.
Согласен, это выбор каждого ради чего он каждый день ходит на работу (ради денег, классного продукта, команды, принадлежности чему-то большому и т.д.). Главное, чтобы за этим "мне не интересно" не скрывалась идея, что теперь можно не следить за результатом.
Не понял эту мысль, у нас наоборот работник очень даже хорошо защищен и уволить за некачественную работу иногда очень нетривальная задача с риском пойти под суд и восстановить работника.
Я это понимаю, более того, я выражаю свою точки зрения и любой читатель Хабра может согласиться или нет с ней. Я не заставляю вас думать и действовать также.
Я видел разные команды и людей, где-то работали ради идеи/продукта (как с хорошей оплатой, так и без), где-то ради денег или чего-то еще. Есть люди, которым нравится продуктовая разработка, кому-то нравится заказная (аутсорс, аутстафф и т.д.).
Каждый из нас сам выбирает где, зачем и на каких условиях он будет работать, а также все ли фиксировать на бумаге или хватит лишь слова.
А можете более детально раскрыть вашу позицию относительно работы наемным работником?
Вопросы, например:
1) ради чего работаете?
2) за что вам платят деньги по вашему мнению? что является результатом вашей работы?
3) что вы должны и не должны работодателю?
4) что работодатель должен/не должен вам?
Давайте начнем с главного - вы, устраиваясь на работу, изначально подписываетесь под то, что результат ваших трудов принадлежит работодателю (хотя ваше авторство никто не оспаривает). Вы изначально подписываетесь под то, что на вас будут "ездить" и вы будете получать за это деньги.
Значит ли это, что теперь свою работу надо делать спустя рукава? Я считаю, что нет и если я накосячил, то моя обязанность встать посреди ночи и починить свой косяк. Это, в том числе, часть вашего контракта с работодателем (делать свою работу хорошо и отвечать за результат). Бывают ли спорные ситуации, где косяк роде бы не твой - да бывают, но мы работаем командой и иногда нужно помогать коллегам.
Попутно у некоторых людей возникает вполне логичное желание - сделать классный продукт, да он формально не твой, но по сути своей он был создан тобой лично (или твоей командой). Не вижу ничего плохого в том, что люди хотят достигнуть каких-то вершин на работе, выполнить свой challenge.
Возвращаясь к вопросу "Где быть личности человека/автора?" - да везде, вы никогда не перестаете быть личностью, что на работе, что вне ее. Вы можете быть согласны/не согласны с чем-то, можете соглашаться или сопротивляться решениям. Да вы каждую секунду личность, принимающая те или иные решения.
Если вам не нравятся правила найма - работайте на себя на своих условиях или найдите компанию под ваши запросы.
P.S. я сам сейчас менеджер, периодически что-то делаю руками сам (помогаю команде) и за время роста с начальной позиции в ИТ до текущей каких-то принципиальных изменений не было. Как старался делать свою работу хорошо, так и делаю и не вижу тут поинтов про эксплуатацию (мне за это платят и я соглашаюсь на такие условия). Когда мне что-то категорически не нравилось и я не мог это поменять - менял работу и находил более адекватные (под свои запросы) места.
В большинстве случаев всегда найдется человек умнее вас. Стоит ли его нанимать к себе в команду - кмк стоит, если он вам подходит по софт/хард скиллам. Никогда не поздно учиться, в том числе техлидам.
Еще вопрос, что понимать под своим детищем, например, это может быть challenge-история в духе "смогу ли сделать с учетом таких ограничений". Ну т.е. человек вполне понимает, что продукт (внутри которого challenge) не его, а компании. Но мотивация не в самом создании продукта (и владении им) - конечная цель в достижении результата (крут, смог и т.д.). Более того в ряде ситуаций вообще создается продукт под конкретные условия и кроме как в этом месте применить его нельзя. Вернее можно, но тогда придется условия другого места привести к необходимым для внедрения, что не всегда допускается.
Кмк зависит от ситуации - роли могут совмещаться (техлид + еще какая-то) и степени влияния на продукт также зависят от команды. Не везде и не всегда вы будете просто прослойкой. Более того, правильным решением будет команда, которая слушает своих участников, а не реализует задачи сверху вниз. Это не всегда и не везде может работать, но дает очень хорошие плоды
Не все из перечисленного есть у любого руководителя. Например, бюджеты могут быть у вашего начальника на вашу команду, но вы ими напрямую не управляете (скорее рекомендуете ему что-то включить). Служебные записки писал пару раз в жизни и в ИТ особо не встречал.
В тему "настоящего" начальника предложил бы меньше на эту тему рефлексировать. Если вы управляете людьми, процессами - то вы вероятно уже начальник. На сколько хороший - другой вопрос, но сами регалии в духе
тут имхо малозначимы. Они могут быть как у хорошего, так и у плохого руководителя. Развивайтесь, достигайте новых целей и поувереннее в себе :)
Спасибо. Дельные советы, что-то уже делаю, часть заберу в копилку)
Рад, что статья оказалось полезной :)
Переключения контекстов это прямо часть жизни играющего тренера. С одной стороны - развивает многозадачность, с другой - получаешь расфокус со всеми вытекающими.
К слову, это хороший показатель, что, возможно, менеджмента уже слишком много и "пора выбирать". Если вы один 15 человек напрямую менеджите (без подчиненных лидов), то кмк это прям достижение, либо команда хорошая. Столько в прямом подчинении имхо сильно тяжеловато.
Одна из целей бизнеса - развитие сотрудников внутри компании, вместо найма извне.
Плюсы я описывал в блоке плюсы/минусы - детально смотрите там. Немного дополню/обобщу именно будущего играющего тренера (еще никогда не был лидом). Но это тоже зависит от зрелости процессов:
вам дают возможность роста в управление/менеджмент, не требуют экспертных знаний в управлении;
хорошая возможность понять нравится/не нравится менеджмент. Может это вообще не ваше и в мечтах было по-другому
рост постепенный с менторством от опытных коллег;
развивается многозадачность и улучшается взаимодействие с командой
Ничего особенного на них не навешивали, где-то не доглядели (процессы еще не были отлажены), где-то человек сам понял, что управление не его (и это отчасти даже плюс - вовремя понять, что это "не твое"). В общем причины были разные.
Если вам проще считать, что компания всегда хочет вас "поиспользовать" (без какой-либо компенсации) - ваше право. Такое часто встречается, но бывают и исключения.
Поделюсь своим опытом, у меня опыт из QA, DevOps, разработки. Есть вещи, которые я знаю хуже чем мои подчиненные, но мой общий бекграунд и разностороннее понимание одной и той же проблемы дает ощутимые преимущества при решении сложный кейсов. Я это не ради похвалы себя пишу, а чтобы показать, что это работает. Конкретно в играющем тренерстве: если вы не были разработчиком, то вам будет сложнее ими управлять, т.к. вы не знаете специфики. Научиться этому можно, но потребуется время.
Такой вариант вполне возможен. Но это не означает, что играющее тренерство не работает в 100% случаев.
Соглашусь, за этот опыт придется заплатить (возможно даже обеим сторонам). Выбор должен быть осознанным как со стороны компании, так и сотрудника. И, повторюсь, крайне желательно иметь опытного ментора/наставника, чтобы он помог без потерь пройти этот этап роста в руководители.
Рост в лидов через играющее тренерство практикуется в ЦИАН достаточно давно, накоплен большой опыт, набиты шишки. Сейчас процесс уже отлажен, за каждым тренером закреплен ментор, который следит за ростом и проблемами + предлагает решения. Если нужно больше деталей - скажите.
Я явно обозначил, что работа играющим тренером это компромисс
Как долго человек будет работать в таком формате (и ради чего) решается ситуационно, это зависит от ряда факторов. Причем решение принимает как компания, так и человек.
Я знаю кейсы, когда такой формат помогал растить руководителей, но знаю истории, когда он же их окончательно выжигал и люди уходили из профессии. Здесь нельзя четко сказать "это плохо или хорошо", в разных ситуациях ответ будет разным.
В последнем абзаце вы фактически спрашиваете стоит ли растить лидов или брать их всегда снаружи. Тут каждая компания сама решает хочет ли она вкладывать деньги в человека. У обоих вариантов (растить или брать снаружи) есть свои плюсы и минусы.
Отдельно добавлю, что
сильно зависит от компании (ее политик, правил и норм) и совсем не зависит от принятых форм управления, а также вашей конкретной позиции в компании
По поводу размера команды - я об этом писал в последней части
По фазе продукта - имхо, зависит от ситуации и распределения ролей. Но как дополнительный фактор тоже допускаю.
Абсолютно согласен, это не универсальный вариант для всех. Есть как плюсы, так и минусы, среди которых как раз риски выгореть, уйти из профессии и т.п.
Заходить в это направление нужно осознанно и, крайне желательно, с внешней поддержкой опытного коллеги-руководителя. Со стороны, чаще всего, лучше видно когда что-то идет не так, а опытный коллега может дать дельный совет или вовремя остановить.
Непонятно что за чудо задача была, которую удалось быстро решить (цитата «Они копали котлован ложками») с помощью Ruby и не получилось на Java/Python за Х месяцев/лет. Можете хотя бы общее представление дать о задаче?
Еще, если не сложно, расскажите, пожалуйста, для каких задач Ruby хорош, а где откровенно бесполезен и нужен какой-то другой язык программирования.
Мы не используем Keycloak на сайте ЦИАН, он используется во внутренних сервисах. Возможно я неправильно понял вопрос, но Keycloak сам не деплоит приложения, он используется для аутентификации/авторизации внутри приложений.
У нас есть два сценария использования:
1) если потеря сессии не важна, то просто ничего не делаем. При входе в сервис пользователь получит редирект, уйдет в Keycloak и там авторизуется (в т.ч. автоматически, если в Keycloak сессия еще не протухла), далее редиректом вернётся обратно в сервис уже аутентифицированным. Этот работает только в случае, когда у вас один инстанс приложения, в противном случае будут постоянные редиректы с разных инстансов и все сломается.
2) если сессия важна, то в этом случае подключается распределенный кеш (в нашем случае Ignite), в котором хранятся все сессии пользователей. В этом случае любая сессия будет известна всем инстансам/сервисам, подключенным к кешу. Для корректной работы этого сценария все сервисы должны использовать куки одного и того же домена.