Нам пишут:
«Хм, а дайте плиз совет.

Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.

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

Есть ли способы как-то улучшить ситуацию?»

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

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

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

Ниже мы расскажем о некоторых интересных и нетривиальных случаях.

Продолжаем цикл наших статей о центрах мониторинга кибератак для начинающих. В прошлой статье мы говорили о Security Monitoring, инструментах SIEM и Use Case.

Термин Security Operations Center у многих ассоциируется исключительно с мониторингом инцидентов. Многим сервис-провайдерам это, в принципе, на руку, поэтому мало кто говорит о том, что мониторинг имеет ряд серьезных ограничения в плане защиты от кибератак.

В этой статье мы на примерах продемонстрируем слабые места мониторинга инцидентов ИБ, расскажем, что с этим делать, и в конце, как обычно, дадим несколько практических рекомендаций на тему того, как провести аудит защищенности инфраструктуры своими силами.

Не так давно совместно с Digital Security мы провели пентест своей корпоративной wi-fi-сети. Сегодня с коллегами расскажем, что может угрожать беспроводной сети, построенной на базе WPA2-Enterprise с аутентификацией по доменному аккаунту, и как от этого защититься.

Одно из правил управления временем — Если есть человек, которому можно делегировать выполнение задачи — делегируй.

Предыстория

Как я докатился до того, что — Я, системный администратор! — стал задаваться вопросами работы 1С?
Тирада в моей оригинальной статье, которую вряд ли кто читал, касалась того, какие лентяи 1С разработчики, и сами производители 1С, что одни понаделали много функций, но другие недостаточно хорошо описали, третьи поленились разобраться, а свалили всю рутину на системных администраторов, которым делать-то нечего, кроме как за элитой IT подметать. Думаю, здесь никто меня не похвалит за такие рассуждения. Хотя и похвалы особо не ищу. Единственная цель — чтобы это пригодилось кому-то, кто правильный лентяй-админ, и не любит заниматься одним и тем же помногу раз. А теперь о том, как это было.
Я столкнулся с таким положением дел, что всем сотрудникам наши 1С разработчики добавляют базы ручками, присутствуя на рабочем месте сотрудника, либо просят это сделать нас удалённо, подключившись к рабочему столу пользователя и мышкакликанием все повторить.
Выглядит это так:

— Миша, добавь Васи Пупкину базу: 1C-server:1551 «buh_prod»
— А как её назвать?
— Бухгалтерия

И не думайте, что в следующий раз, этот 1С разработчик скажет мне, что эту базу можно назвать именно также. Как следствие, у нас одна и та же база у разных сотрудников называлась по разному. Красота, не так ли?!
Ещё одна сторона этой проблемы в том, что Сотрудник должен быть на месте, компьютер включен, и у него должно быть время (5 мин), чтобы я мог всё это сделать. Если сотрудника нет на месте, то вы можете себе предположить, сколько от меня требуется трудозатрат, чтобы выловить этого сотрудника, согласовать с ним время и сделать это. А если этот сотрудник в удалённом офисе, на ноутбуке, и бывает в сети крайне редко, плюс разница поясов Владивосток — Москва, то это ещё добавляет остроты ощущений. Конечно, можно ещё ярлыком в почту бросить, но этим у нас 1С разработчики очень крайне редко пользуются — или не умеют, или не хотят, или за нас переживают, что без работы останемся, за что им отдельная благодарность и лучи поноса.
Баз у нас порядка пятнадцати. У каждой группы отдельный набор баз. А есть и такие, у кого строго индивидуальный список.
Следующая картина вам ещё больше понравится.
Поступает распоряжение от главы 1С'ников, что нужно трём отделам изменить базу, т.к. она переехала на другой сервер. Дальше не буду тратить буквы, т.к. всё что я описал выше множите на тридцать человек, двадцать из которых в другом офисе или даже другом городе. Классная задачка.
Не помню, сколько раз, я, таких суматох вынес, но было их больше десяти. После чего мне стало интересно, какие способы оптимизации этого процесса есть по unix-way'ю.
И стал я читать… Читал долго… Читал упорно… Документация 1С в справке мне совершенно не понравилась — написано так, как будто бы я уже это делал, поэтому большую часть идеи они оставляют между строк. Лучи поноса в написателей встроенной справки 1С. Как обычно это бывает, более-менее понятную инструкцию нашел на личном блоге, не помню уже кого.

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

Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.

Сегодня наш гость — Виктор Тарнавский, глава разработки в нескольких проектах компании «Яндекс». В частности, год назад он унаследовал «Яндекс.Метрику» от прежнего руководителя — Артура Сиулина.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Книги.
Я считаю, что важнейшим инструментом получения скилов системного администрирования являются именно они — книги.
Нет специальных факультетов, обучающих «админству» — каждый постигает это самостоятельно. Путем проб, ошибок и боли, потере важных данных различных злоключений.
В начале пути сложно определиться, что же нужно прочесть — ведь массив информации столь огромен!
В данном посте я хочу собрать наиболее важные и значимые труды для системных администраторов.
Уклон будет на *nix админство, но, надеюсь тема окажется небезынтересной и для Windows коллег и в комметариях они заполнят мои пробелы.
Пост субьективен и отражает лишь мой собственный опыт — я раскажу о книгах, которые помогли моему становлению.

Здравствуйте! Начитавшись публикаций на тему строительства ЦОД небольшого хостинг провайдера, а так же «как сделать серверную комнату своими руками», от людей, которые, видимо, не знали как сказать, зачем надо заказывать их услуги, я решил изложить свой опыт строительства небольшого узла связи в течение этого года, для размещения, с последующей регистрацией в Роскомнадзоре, таких объектов, как ОТМУС, ТЗУС, СПД.

В этом году приходилось настолько много информации искать и применять, что я почувствовал свой предел в запоминания полезной информации. Поэтому мне сложно сразу вспомнить откуда я брал информацию (я говорю о приказах Минкомсвязи, Мининформсвязи, Роскомнадзора, СНИП, ВСН… ).

Под катом я постараюсь поверхностно пройтись по всем аспектам, по которым надо принять решение и реализовать в вашей аппаратной.