В этот день, практически в канун католического рождества, 23 декабря 1996 года, вышла оболочка Bash версии 2.0. Последний мажорный релиз на сегодня — это версия 5.3. Сейчас Bash встроена почти во все версии Linux и MacOS, а также заявлена как встроенный компонент Microsoft Windows.

Bash поставляется по умолчанию почти во всех дистрибутивах Linux и современных версиях MacOS и, как ожидается, вскоре он станет неотъемлемой частью Windows Terminal. Bash действительно повсюду и это не фигура речи. Как до этого дошло? В сегодняшней статье мы глубоко исследуем этот вопрос, задавая вопросы именно тем людям, которые причастны к разработке оболочек.

Что делать, если ты джун и хочешь попасть в хорошую ИТ-компанию? Очевидный ответ — учиться, развиваться, осваивать Linux и кодить, кодить, кодить. Рано или поздно тебя заметят и пригласят на работу в компанию твоей мечты. На первый взгляд, такое бывает только в книжках и позитивных речах инфобизнесменов: в реальности же крупные компании не сильно жалуют джунов. Однако варианты все-таки есть.

Мой путь к трудоустройству занял 2 месяца — я потратил их на прохождение обучения по специальной программе подготовки инженеров Linux, после которой попал в штат МойОфис. Под катом рассказываю, как это было, с чем я столкнулся и что нового узнал о профессии.

Вместо предисловия

Привет, Хабр! Меня зовут Саша Козлов, я занимаюсь разработкой инфраструктуры и системным администрированием в Авито последние три с половиной года. Я расскажу, как мы масштабировали и модернизировали со временем нашу работу с инфраструктурным кодом и вывели её на качественно новый уровень.

Мы отвечаем за полный цикл управления оборудованием: от закупки и монтажа в ДЦ до доставки до конечного потребителя. Речь пойдёт об уроках, которые мы вынесли за последние несколько лет, работая с тысячей единиц оборудования и несколькими тысячами единиц конфигурирования.

Puppet — это система управления конфигурацией. Он используется для приведения хостов к нужному состоянию и поддержания этого состояния.

Я работаю с Puppet уже больше пяти лет. На мой взгляд, его официальная документация хороша для тех, кто уже знаком с Puppet, а для новичка она сложна — сразу даётся много новых терминов; непонятно, в каком порядке читать. Эта статья — по сути переведённая компиляция ключевых моментов из официальной документации, которая позволит новичкам быстро вникнуть в суть Puppet. Я переупорядочил информацию, чтобы постепенно рассказать про все сущности и термины.

Привет, Хабр! Меня зовут Александр Лукьянченко, я тимлид команды, которая занимается платформой в Авито. В этой статье я расскажу о проблемах, которые возникали у нас при построении платформы для инженеров и том, какие технические решения мы использовали, чтобы эти проблемы устранить. Текст охватывает ту часть наших наработок, которые потенциально можно переиспользовать другим компаниям.

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

Помимо того, чтобы быстро восстановить работу сервиса, важно избежать повторения проблем там, где это возможно. А там, где предотвратить аварии совсем нельзя, — минимизировать ущерб как для пользователей, так и для сотрудников.

Поэтому кроме круглосуточного мониторинга у нас есть процесс разбора инцидентов. И сами пожары на проде, и работы по анализу проблем мы называем live site review или LSR. Я отвечаю за часть работ с LSR после пожаротушения и хочу поделиться нашими наработками.

Задумывались ли вы о том, как изменить конфигурацию сразу на нескольких сетевых устройствах? Что, если нужно сделать это на всей сети с сотнями и тысячами единиц оборудования? А что, если приходится делать это каждый месяц на железе от пяти разных производителей? Очевидное решение для подобных задач — автоматизация. Но реализовать её можно не одним способом, а в процессе наткнуться не на одни грабли.

Меня зовут Вадим Воловик, и я руковожу проектами разработки в Yandex Infrastructure. Наша команда NOCDEV отвечает за автоматизацию сетей всего Яндекса. Давно хотелось рассказать о задачах такого масштаба, но по ходу написания материала стало понятно, что тема тянет на целый цикл. Так что мы с коллегами расскажем о самых интересных примерах автоматизации в отдельных постах.

В этой статье проведём небольшую экскурсию по нашему сетевому «хозяйству» в десятки тысяч устройств и остановимся подробнее на том, как при таком объёме мы автоматически обновляем конфигурации.

Я отвечаю за подготовку и репетицию докладов в Московском клубе программистов. Не всем нашим докладчикам нужна помощь, но если нужна, помогать им буду я. За последние шесть лет мне довелось прослушать несколько десятков докладов. На самом деле я не знаю, сколько их было — никогда не считал — но, возможно, их уже больше ста.

Доклады были разными. Я хотел, чтобы они были захватывающими и полезными, так что мне пришлось разобраться в том, как сделать интересный доклад. Оказалось, что эти знания востребованы и среди программистов — начинающих докладчиков, и среди деврелов. В конце концов я решился написать статью на эту тему.

Материала оказалось много и статьи получилось две. Эта первая — о том, как придумать тему доклада.

• Процесс эволюции (через что мы прошли за то время, пока я был в компании).
• Автономность — хорошо это или плохо, и почему у нас это было.
• Концепция Servant Leadership.

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

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

Прийти новым руководителем в уже сформированный коллектив, не разрушить команду, сохранить и увеличить её производительность — очень непросто. Особенно в случае с самоорганизующимися Agile-командами: когда от руководителя ожидается не директивное управление, а качественное сопровождение. Такие команды настроены не на подчинение, а на сотрудничество, которое ожидают и от руководителя. Повести за собой, действуя на равных и не имея сформированного авторитета, — задача, требующая терпения, настойчивости и хороших навыков коммуникации. И решить эту задачу нужно в достаточно короткий период адаптации.

Что такое дизайн информационных систем

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

7. Советуйте «быть аккуратными». Будьте «разумны» и подталкивайте других участников совещаний к «разумности», к тому, чтобы они избегали спешки, которая может в будущем вызвать неудобства или сложности.

8. Беспокойтесь о правильности каждого решения, поднимайте вопрос о том, будет ли рассматриваемое действие относиться к юрисдикции группы или оно может вызвать конфликт с политикой какого-то более высокого эшелона.

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.