Фраза «пустой пароль» однажды использовалась в тексте и во избежание некорректного её прочтения исправил, спасибо.
Речь про строку в /etc/shadow определённого вида (root::…), что указано в описании работы скрипта. Такая строка означает, что пользователя root пустят в систему без даже просьбы вводить какой-либо пароль. В Ubuntu, например, по умолчанию делают root:!:…, что действительно означает уже совсем иное: никакой пароль не подойдёт (хэш не совпадёт).
Спасибо за замечание. По существу — он разве что «усложнил» цепочку трафика для troubleshooting'а, о чём сказано в тексте. Из хаба Kubernetes статью убрали.
P.S. А в заголовке K8s по той причине, что хотим сделать такой цикл из материалов, объединённых тем, что все они будут из практики эксплуатации приложений в Kubernetes, однако с самим K8s напрямую могут быть не связаны. Их суть в первую очередь о «просто интересном опыте» и более «системных» выводах из него (что вообще случается в нашей практике, как подходить к вопросам troubleshooting'а и т.п.).
Большая разница — мы это наблюдаем на практике. Появляется бОльшая автономность, перераспределяется ответственность. Тимлид не просто влияет на подбор (и не только сотрудников, но и новых клиентов), а именно принимает решение (вместе со своей командой — обычно привлекается хотя бы его заместитель), тут же и обратная сторона — отвечает (перед командой) за последствия. Команда может регулировать распределение финансов, в команде становится более прозрачным влияние работы каждого на общий результат.
Тема поднята хорошая, но просто невозможно охватить всё и сразу в интервью (тут вопрос больше о его целях у самих авторов).
«5-6 человек уйдут из компании» — это же вряд ли сразу случится (а если столько же инженеров сразу уйдут, тоже хорошего мало). И вообще: когда люди уходят, им находят замену, разве нет? :-) Поэтому в таком срезе вопрос немного странный.
В целом же, вот ещё несколько тезисов по теме:
Хорошо поставленный процесс означает, что он будет (пусть хуже и какое-то время, но будет) продолжать работать и в случае ухода некоторых людей. Т.е. клиенты не перестанут сразу же к нам приходить даже в том случае, когда ключевой(ые) человек внезапно уйдёт.
Отдельные подразделения маркетинга, продаж для каждой команды — это большой overhead. Когда это разделяемый ресурс, всё получается очень красиво. По крайней мере, в наших масштабах и процессах сейчас это так.
Команды участвуют и в маркетинге, и в продажах. Не на всех этапах, конечно, но всё же. Тимлиды встречаются с потенциальными клиентами (чтобы обсуждать технические вопросы). Инженеры, например, помогают со статьями на хабру, описывая свой опыт. Есть ещё доклады на конференциях, где тоже задействованы представители команд.
Это больше похоже на «хотелось вот такое написать, но не знал, к чему бы…».
«Продукты» бывают только от вендоров и только для «enterprise» (и что конкретно вы называете этим термином, он довольно расплывчат)? Или вы считаете, что сам по себе Kubernetes (не будучи каким-то вендорским проявлением…) в принципе не готов к enterprise, поэтому не «продукт»?
Если вы хотите сказать, что ни один Open Source-проект сам по себе продуктом не является (так читаются рассуждения про L3 и т.п. Хотя природа Open Source такова, что патчи потенциально может сделать буквально каждый «продвинутый пользователь»), то больше вопросов возникает к слову «продукт». Но это какая-то демагогия про слова, а не суть…
Поиск сотрудника происходит усилиями HR'а и к этому не относится. Речь про адаптацию. Эта сумма — фактически ЗП нового члена команды на испытательный срок, но устроено всё таким хитрым образом (вместо прямой оплаты этой ЗП из «федерального бюджета» компании, как было раньше), чтобы сама команда была мотивирована минимально рисковать и брать людей, в которых она уверена/которые ей подходят. (Команда сама принимает решение о том, берёт ли такого-то найденного и протестированного человека к себе.)
Скриншот по ссылке из старого теста, который был сильно более "классическим" сисадминством. В актуальном от этого ушли больше в сторону того, о чем выше (хотя и задания по системной части остались, т.к. мы считаем их знание критичным). Менять (сносить/переставлять в системе) можно радикально буквально все — на это ограничений в задании нет
Известный нам рынок труда ещё не готов к тому, чтобы требовать от каждого неплохих практических знаний Kubernetes на старте работы в компании… :-) Этому мы уже обучаем внутри. Сборка/запуск приложений, впрочем, вполне близки к реальности, при этом компетенции — более массовые.
Мы в очень общих чертах писали о нём здесь. Это специальная виртуальная машина, попав на которую, системный администратор сначала пытается заполучить [чуть спрятанное] задание, а затем — выполнить задачи на той же машине. Эти задачи связаны с починкой/настройкой служб, которые могут быть специально сломаны хитрым образом, а также со сборкой/запуском приложений на разных языках/платформах, которые, понятное дело, имеют ошибки, возникающие на разных этапах (пример кейса — это приложение перенесли с другого сервера и вот здесь оно почему-то перестало работать).
«Пускание пыли» (по крайней мере, в массе) отпадает хотя бы по той причине, что это происходит подозрительно часто и даже от тех, кто сам понял, что не возьмут (зачем им уже производить какое-то впечатление?). Я не утверждаю, что нет тех, кому такое сомнительно, но конкретно у нас таких [из попавших на сам тест] — явное меньшинство.
И ещё момент: у нас не разработчики, а DevOps-инженеры.
Всякое бывает… Мы вот недавно писали про Reddit, где:
В начале 2016 года у сервиса, реализованного в виде монолитного приложения, было всего около 20 инженеров [..] Однако этот год принёс большие перемены: уже к его концу в компании работали более 60 инженеров (а к концу 2018-го года их число увеличилось до 200, т.е. всего за 3 года случился 10-кратный рост штата).
И всё выглядит так, что ребята ещё на плаву ;-) Но этой кадровой революции внутри компании сопутствовала и технологическая…
Речь про строку в /etc/shadow определённого вида (
root::…), что указано в описании работы скрипта. Такая строка означает, что пользователя root пустят в систему без даже просьбы вводить какой-либо пароль. В Ubuntu, например, по умолчанию делаютroot:!:…, что действительно означает уже совсем иное: никакой пароль не подойдёт (хэш не совпадёт).Нет, всё это было в статье изначально при публикации. Сам ее публиковал, так что знаю точно :-)
P.S. А в заголовке K8s по той причине, что хотим сделать такой цикл из материалов, объединённых тем, что все они будут из практики эксплуатации приложений в Kubernetes, однако с самим K8s напрямую могут быть не связаны. Их суть в первую очередь о «просто интересном опыте» и более «системных» выводах из него (что вообще случается в нашей практике, как подходить к вопросам troubleshooting'а и т.п.).
Большая разница — мы это наблюдаем на практике. Появляется бОльшая автономность, перераспределяется ответственность. Тимлид не просто влияет на подбор (и не только сотрудников, но и новых клиентов), а именно принимает решение (вместе со своей командой — обычно привлекается хотя бы его заместитель), тут же и обратная сторона — отвечает (перед командой) за последствия. Команда может регулировать распределение финансов, в команде становится более прозрачным влияние работы каждого на общий результат.
«5-6 человек уйдут из компании» — это же вряд ли сразу случится (а если столько же инженеров сразу уйдут, тоже хорошего мало). И вообще: когда люди уходят, им находят замену, разве нет? :-) Поэтому в таком срезе вопрос немного странный.
В целом же, вот ещё несколько тезисов по теме:
«Продукты» бывают только от вендоров и только для «enterprise» (и что конкретно вы называете этим термином, он довольно расплывчат)? Или вы считаете, что сам по себе Kubernetes (не будучи каким-то вендорским проявлением…) в принципе не готов к enterprise, поэтому не «продукт»?
Если вы хотите сказать, что ни один Open Source-проект сам по себе продуктом не является (так читаются рассуждения про L3 и т.п. Хотя природа Open Source такова, что патчи потенциально может сделать буквально каждый «продвинутый пользователь»), то больше вопросов возникает к слову «продукт». Но это какая-то демагогия про слова, а не суть…
— как-то совсем скучно…
Скриншот по ссылке из старого теста, который был сильно более "классическим" сисадминством. В актуальном от этого ушли больше в сторону того, о чем выше (хотя и задания по системной части остались, т.к. мы считаем их знание критичным). Менять (сносить/переставлять в системе) можно радикально буквально все — на это ограничений в задании нет
С определённых (и уже довольно давних) времён тест у нас проводится удалённо. О своём прогрессе/результате кандидаты пишут в Slack.
И ещё момент: у нас не разработчики, а DevOps-инженеры.
И всё выглядит так, что ребята ещё на плаву ;-) Но этой кадровой революции внутри компании сопутствовала и технологическая…