недосказал мысль, какое на этой основе предлагает решение, почему и как он его обосновывает.
Eсли под «сделать дизайн» вы понимаете выдать рез-тат работы дизайнера, то это не проверишь и за целый день.
В дизайне на мой взгляд важно получить исходные данные как можно точнее. Тот кто проектировал понимает что это все не о том сколько разных протоколов IGP существует и прочей хероте, оценивать нужно какие вопросы задает собеседуемый и какое на этой основе предлагает решение.
В траблшутинге то же самое, нужно смотреть какие вопросы задает кандидат, смог ли собрать максимальные сведения и «описать проблему», наксолько он последовательный, гадает или же делает нормальный step-by-step траблшутинг, ИТД.
Я подымал, администрировал и периодически привлекаюсь к администрированию Zimbra. У Zimbra замечательные возможности масштабирования и распределённости. Я подымал распределённую систему серверов из 2 штук. Один был в европе, другой был в китае. В моём случае был главный в европе сервер, который рулил и вторым сервером в китае. Когда возникали проблемы с китайскими отправками из китая, можно было легко сказать серверу слать всё через европу, и наоборот. Если вы считаете что это не нужно, то могу сказать, что в случае с китаем, можно постоянно ловить нежданчики, ответ на которые не знает провайдер их местный, или не хочет говорить, а на просьбу сделать PTR запись, они спрашивали — А что это?

А можно сделать, чтобы сервера были равнозначными. И менять конфигурацию из любого места. Вот с дублированием хранилища данных я не разбирался.
Самая большая жопа для админа, когда вам нужно будет делать Backup или переносить ящики (в смысле хранилще почты ящика), то тут в бесплатной версии нет вам помощи и вы извращаетесь, как хотите.

Под капотом конфигурация всё рулится LDAP'ом.

Если нужно довлкючить ещё один сервер в каком-то новом регионе, то это легко делается.
Если вы хотите расслоить SMTP-сервер, хранилище, веб-клиент — это тоже пожалуйста.
У меня было два веб-интерфейса и в китае и в европе. А клиенты (почтовые) были во Владивостоке, в Китае и Москве. Так вот я мог с любого интерфейса попасть и на почтовый ящик расположенный в китае, и на почтовый ящик в Европе.
За три года я не ловил никаких неизведанных проблем, которые бы требовали вскрывать капот. Все проблемы были с Китаем, разработчиками нашими, которые успешно срали на неизведанные номера и до последнего не сознавались.

Кстати! Очень гениальное решение одного сотрудника в Китае. Приложение на 1С слало через Zimbra клиентам уведомления. В карточке клиента в 1С нельзя было оставить пустым поле почты, и нельзя было отключить рассылку. Поэтом сотрудник реши эту проблему исправлением почты на несуществующую. И вот такое говно копилось в почтовой очереди и ни одна собака не сознавалась. Потом это как-то выяснили уже после моего увольнения.

Полтора года уже работает без пристального внимания администратора. Кроме меня никто в него не лез — боялись, начальник IT отдела наш ящики там заводит только, ну и иногда ворота меняет, когда в китае фигня с сетью творится.

Если у вас многофилиальная, территориально распределённая организация, то лучшего, бесплатного и удобного (на сколько это возможно) решения вам не найти. Exchange с многофилиальной структурой и с хорошей отказоустойчивостью и независимостью офисов, вам встанет о-о-о-о-очень дорого! В Zimbra это всё расковыривается даже по их безобразным инструкциям, если есть понимание о SMTP, IMAP, LDAP, DNS, Proxy.
Касаемо прожёрливости Java — скажите, какие минимальные требования к системе у Exchange? — Zimbra легко уложится в эти рамки.

Если вы захотите платную Zimbra, то купите Exchange. Вам её даже продать не смогут здесь в России. Когда я задавал вопрос о покупке пару лет назад, мне ни один интегратор Российский не ответил на письмо, а ответили из Европейского офиса. Не стоит расчитывать с Zimbra хоть на сколько-нибудь адекватную поддержку и сопровождение со стороны интеграторов. Только если вы Linux'ятник извращенец, который не совсем оторван от жизни, чтобы подымать всё на голых Postfix, Dovecot, LDAP, CalDav, CardDav, то Zimbra ваш вариант.

Я начинал с Book of Postfix — считаю эту книжку достаточной для целостного понимания, как устроена почта.
Вопросы на дизайн имеют место быть, но не «нужно сделать дизайн», это за 10 минут не делается. Но что-нибудь типа «расскажите о плюсах и минусах BGP RR и full mesh».
Траблшутинг тоже можно спрашивать, но проблема с такими вопросами в том, что полной картинки не обрисуешь, а в отсутствии рамок кандидат теряется, ибо возможностей куча. «Сухой» траблшутинг на интервью очень сильно отличается от настоящего.
А вопрос про сорс и дестинейшн в трейсе это как раз то, что мало кто знает или активно помнит. Тут надо думать, на месте взвесить что там, скорей всего, должно быть. Как я и говорил на интервью, если кто-то помнит специфические номера портов, меня это настораживает.
Наталья, а можно контакт как-то Ваш получить в личку?
Нужно продать товарища выгодно в хорошую компанию. :)
Привет.
Подкаст получился хороший и годный. Спасибо ведущим.

Оставлю пару копеек:
— Забыли упомянуть совсем про паблик фолдерс. Незаслуженно, ибо сразу же и лучи любви и ненависти были бы. Про общие ящики вспомнили, а про этих нет. Предположу, что это потому, как пользуются в России ими наверное поменьше, чем заокеанами, где их очень любят как инструмент совместной работы.
— Помимо переговорок есть еще ресурсные ящики (оборудование). Тоже можно с успехом пользоваться.
— По поводу сожаления, что нет мдаемона под винду. Это так, но поскольку есть давно такой продукт как Керио, который умеет хоть винду, хоть линукс хоть апплайнсы под варю, то я бы начинающему знакомиться с почтой порекомендовал бы именно его ставить. Мдаемон уже не торт, есть более модные и молодежные продукты )
— Документы, про которые говорил Серега, называются IPD technet.microsoft.com/en-us/library/cc936627
— Вроде бы сказали все и обо всем, и добавить-тот по существу больше нечего.
— В конце, как всегда общее впечатление чуть подпортили петросянские вопросы по поводу Send-on-Behalf и срочного и ускоренного обновления GAL. Это почти как прибежать слушать Лохвицкого и задавать ему вопросы про отличие Enterprise и Standard редакций, одного полета вопросы.
Тут можно только развести руками и посоветовать, как говорил Серега пойти и припасть к технету, там вся информация есть. Можно при желании хоть каждые пять минут обновлять гал, как всегда здесь остается только вопрос — зачем? Чтобы что?
В практике есть кейсы по решению подобных проблем, но ноги там растут от пункта «я не умею в документацию выше», либо от работы скриптинг агентов или прочего самописного ада + репликации между площадками. В любом случае, задачу можно решить. Вводных только мало, а без них вопрос повис в воздухе. Задавшему вопрос будет урок, что правильно сформулированный вопрос- половина ответа. Не все сейчас, к сожалению владеют таким искусством. Но это уже отступление от темы.
Проверка знаний на мой взгляд может быть устроена в виде role play game, где вы заказчик которому нужно сделать дизайн, если нанимаете дизайнера, или клиент у которого сеть лежит если нанимаете траблшутера, итд.

Не ну серьезно, какой выбирается сорс и дестинейшн порт UDP пакете у трейсраута? Если честно я только после вашего подкаста открыл таки дамп c трейсом и глянул что там за порт. За 10 лет в теме почему то не пригодилось. Другой момент что трасерт это не та команда которая очень часто используется в траблшутинге сложных проблем связаных с network connectivity. Не говорю что не нужно знать как она работает.
Просто хочу сказать, что бывает что тех. интервью не проводиться совсем, например мой коллега тоже инженер техподдержки большого вендора, перешел таким образом в Orange. Причем последние 5 лет он траблшутил коммутаторы, а ушел проектировать mpls.
Коллеги, а где же ответ на самый главный вопрос: «Кем Вы видите себя в компании через 5 лет?»
Как уже сказал Марат, доверять резюме нельзя практически никогда. Проверять надо всегда.
И тут не столь важно знание всех мелких деталей (хотя незнание базы настораживает само по себе), сколько умение думать на ходу. А для этого надо поставить кандидата в положение, когда у него нет сиюминутного ответа на вопрос, и надо думать головой прямо в процессе.
Если вы знаете лучший способ проверить то, о чем вы говорите — я с удовольствием перейму опыт.
Безусловно нужно.
Об этом говорит и здравый смысл — человек может 6 лет транслировать вопросы с русского на английский и обратно. И опыт — лично собеседовал людей, которые 5-6 лет в индустрии, резюме — хоть завтра в Джунипер, а какие протоколы IGP бывают рассказать не может.
Поэтому технические вопросы стоит задавать, причём независимо от опыта, резюме и вашего личного отношения к человеку.
Впрочем, последний подкаст про собес показывает, что техническое интервью — не самая важная часть)
Нужно ли проверять технические знания у таких инженеров как Мурат? У него 9 лет практического опыта, 6 из которых в техподдержке большого вендора.
Всех деталей все равно не упомнишь, можно конечно заранее готовиться к собесу чтобы ответить на все детали, но на мой взгляд в практике более важно умение быстро найти различные нюансы работы той или иной фичи.
Изображение прекрасно!
Тема глупых девочек-HR не раскрыта. Нужно знать как с ними быть, что бы их некомпетентность обернулась против них.

Наталье спасибо за введение в работу HR профессионала! Было интересно. Теперь нужны рецепты того, как жить и быть, что бы проходить интервью с HR, а в идеале и совершать контр атаки на «глупых девочек».
Доброго времени суток. Отличная статья.
мне кажется или для маршрутизатора Linkmeup_R1 отсутствует конфигурационный файл если зайти по ссылке
Полная конфигурация всех узлов для Common Services.
2 часа по единогласному мнению ведущих — оптимальная длительность. Не утомляющая, держащая в напряжении до конца. :)
  • avatar _KUL
  • 0
Великолепный выпуск! Интересные вопросы, интересные ответы(без секретничества), одно удовольствие слушать!
Один минус — мало 2 часа :)
Получается, что в этом примере даже с учетом исправлений данные не передаются по туннелю между R3 и R4. Чтобы передавались и между ними, я бы сделал ACL на роутерах такие:
R1:
101 10.0.0.0 0.2.2.0 host 10.1.1.0
102 10.0.0.0 0.1.1.0 host 10.2.2.0
(тут маска 0.2.2.0 будет «пропускать» только адреса 10.0.0.0 и 10.2.2.0, а маска 0.1.1.0 только адреса 10.0.0.0 и 10.1.1.0)

R3:
101 host 10.1.1.0 10.0.0.0 0.2.2.0

R4:
101 host 10.2.2.0 10.0.0.0 0.1.1.0
Кстати, если соединить свич Балаган-Телекома с роутером Красн. прямым, а не кросс-кабелем, то все тоже заработате без ввода команд
На свиче Балаган-Тедеком необходимо войти на интерфейс влан 8, который между Московй и Красноярском, после этого он приобретет статус up, хотя и до этой команды роутера Моск. и Красн. видят друг друга. После этой операции все будет работать нормально. Сам вообще не понял почему так. Скорее всего глюк РТ.
Сессия не устанавливается через маршрут по умолчанию. Хотя бы у одного соседа должен быть специфический маршрут.