Сегодняшний урок представляет собой вводную информацию о роутерах Cisco. Прежде чем приступить к изучению материала, хочу поздравить всех, кто смотрит мой курс, потому что видеоурок «День 1» на сегодня просмотрели почти миллион человек. Я благодарю всех пользователей, которые внесли свой вклад в изучение видеокурса CCNA.

Сегодня мы изучим три темы: роутер как физическое устройство, небольшое введение в маршрутизаторы Cisco и начальная настройка роутера. На этом слайде показано, как выглядит типичный роутер модели 1921 производства Cisco.



В отличие от свитча, имеющего множество портов, типичный роутер имеет всего 2 порта для подключения, в данном случае это порты Gigabit Ethernet GE0/0 и GE/1 и разъем USB. Роутер также имеет слоты под модули расширения и 2 консольных порта, в том числе 1 USB-порт. Отличительной чертой роутеров Cisco является наличие выключателя – свитчи Cisco выключателей не имеют. Обычно передняя часть роутера выглядит так, как показано в левой нижней части слайда. На задней панели роутера расположены гнезда для подключения кабелей. В данном случае кабель из слота GE0/0 или GE/1 подключается к свитчу.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3
Лекция 16: «Атаки через побочный канал» Часть 1 / Часть 2 / Часть 3
Лекция 17: «Аутентификация пользователя» Часть 1 / Часть 2 / Часть 3

Привет, Хаброжители!
У нас вновь вышла книга Дж. Рейнвотера.

«Как пасти котов» — это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды программистов. Даже если вы еще месяц назад были блестящим и дисциплини-рованным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руко-водства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач. В таком случае без этой книги вам не обойтись. А может быть, вы — опытный менеджер, желающий пересмотреть свои принципы лидерства? Тогда, опять же, эта книга для вас. Вне зависимости от возраста, пола и социального статуса она поможет вам укрепить свои позиции в роли лидера программистов. Материал изложен довольно компактно и легко укладывается в голове. Стоя в книжном магазине и раздумывая, что же купить, задайте себе один простой вопрос: «Нужно ли мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите: «Да», — а значит, данная книга окажется для вас небесполезной.

Вариантов организации мониторинга состояния пассивных элементов, систем уплотнения WDM не так уж и много, в связи с естественными ограничениями связанными с особенностями оборудования.

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

Покупая продукт или услугу мы часто оперируем таким понятием как качество. Что же такое качество? Если мы обратимся к словарю Ожегова, то там увидим следующее: «совокупность существенных признаков, свойств, особенностей, отличающих предмет или явление от других и придающих ему определенность». Перенося определение на область сетей связи, приходим к выводу, что нам требуется определить «существенные признаки, свойства и особенности», позволяющие однозначно определить отличие одной линии или сети связи от другой. Перечисление всех признаков и свойств обобщаются понятием «метрика». Когда кто-то говорит о метриках сетей связи, он имеет в виду те характеристики и свойства, которые позволят точно судить о системе связи в целом. Потребность в оценке качества лежит большей частью в экономической области, хотя и техническая её часть не менее интересна. Я же попробую балансировать между ними, чтобы раскрыть все самые интересные аспекты этой области знаний.

Всех заинтересовавшихся прошу под кат.

Это 8 Тбит/с (при использовании 80 длин волн с пропускной способностью 100G).

С 2006 года я сдал в эксплуатацию коммутационное оборудование полутора дюжинам банков. И ещё ряду объектов, которые не могу упоминать. Это те самые каналы, где в скорость синхронной репликации нагло и подло вмешивается скорость распространения света в оптоволокне.

Случается, что заказчики сначала строят ЦОДы, а потом задумываются, как связать их при помощи WDM. Аналогию можно привести с транспортными развязками в Москве, когда сначала строят многоэтажные здания а потом понимают, что дорога в две полосы не справляется с транспортным потоком, и строят дорогостоящие трёхуровневые развязки на пяточке земли, хотя куда более логичным было бы заложить место под будущие дороги и развязки, а уже после строить дома.

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

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов

Довольно частый запрос от коллег-менеджеров, который приходится слышать: как повысить ответственность человека?

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

Однако, в жизни все сложнее… Приходится заниматься занудными уточнениями: а сейчас люди как работают? — Ну… безответственно.

Хм, яснее не становится. Хочется ехидно уточнить: “в смысле, бросают жен и детей?”, но в реальности, начинаешь разбираться.

Приветствую, Хабр! В связи с плохим качеством линии меня попросили настроить автоматическое переключение на резервный канал. Для этой цели предоставили роутер MikroTik RB 951Ui.

Думал, что проблем не возникнет… Всего-то настроить проверку канала и маршруты. Но, к сожалению, оба провайдера выдают IP динамически. Сначала я попробовал подставить в маршрут название интерфейса, но пинг не проходил. Прочитав несколько статей, включая зарубежные сайты, но не нашел решения проблемы, которое мне подошло бы. Пришлось знакомится с RouterOS по ближе, а в частности с созданием скриптов…

В определенный момент некоторые предприятия дорастают до того состояния, когда их внутренние информационные системы перестают умещаться в одном серверном шкафу. Тогда руководителю IT-департамента предстоит взвесить все «за» и «против» и решить, строить или не строить серверную. Вариантов может быть несколько: от полного избавления от собственных мощностей и увода их в облака или колокейшн в большом ЦОДе, до строительства собственного мини- (или не очень мини) ЦОДа с блэкджеком.

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

Второй по величине потребитель ресурсов (в данном случае это электричество и расходники) в серверной — это система охлаждения. Ни для кого не новость, что “мощность” системы охлаждения серверной должна минимум совпадать, а в лучшем случае превышать на пару десятков процентов пиковую мощность всего оборудования установленного в серверной. О том, какие системы охлаждения бывают и как сэкономить на эксплуатации таких систем мы и поговорим в этой статье.

Update статьи “Пиши резюме правильно или “умею улыбаться и пеку оладушки”.

Начну с того, что я IT рекрутер. В этом тексте выражено только мое мнение по вопросу составления резюме. Это вовсе не значит что мои коллеги по отрасли считают также. Возможно, с чем то-то они согласны, с чем-то нет.

Да, каюсь, в первоначальном варианте статьи, опубликованном некоторое время назад, я несколько категорично выразила свое мне о наличии и качестве фотографии в резюме. Давайте поступим так: ставить фотографию или нет — решать вам. По своему опыту могу сказать лишь, что:

1. Работая в IT кадровом агентстве, я общаюсь с кандидатами только по телефону и мне психологически комфортнее представлять себе человека визуально. Возможно вам тоже. Часто процесс трудоустройства растягивается на недели, а то и на месяцы. В этот период я веду с кандидатом переписку, общаюсь по телефону и в скайпе. Волнуюсь за него, особенно если процесс рассмотрения резюме почему-то затягивается, а человеку срочно нужна работа. Если история заканчивается хорошо, и кандидата приглашают в компанию — радуюсь. И так изо дня в день, и из месяца в месяц. Человек становится уже в чем-то близким для меня. И не представляя его визуально — чуть сложнее и как-то грустнее, что ли, работается.

Поэтому фото в резюме важно для меня, как для рекрутера.

2. Для руководителя, ищущего специалиста себе в команду — фото в резюме кандидата может быть важно по другой причине: с этим человеком он и его коллеги будут работать по 8 часов в день 5 дней в неделю. И хочется, чтобы человек вписался в команду. Конечно, понять, впишется специалист в команду, или нет, можно только на собеседовании, и то не всегда. Но всех на собеседование не пригласишь, у руководителя мало времени для этого. Фото в таком случае выступает для него одним из фильтров для экономии времени.

Отталкиваясь от этого, решать, размещать ли фотографию в резюме, и какую именно — вам. Я лишь попробовала объяснить, почему это может быть косвенно полезно при поиске работы.

И напоследок, перед тем как вы начнете, уже наконец, читать саму статью, хочу попросить вас — не стесняйтесь комментировать! Ваше мнение для меня очень важно, потому что вы — мои друзья, или коллеги по отрасли или те, кому я звоню каждый день, говоря: ”здравствуйте, я нашла ваше резюме..."

По долгу службы я каждый день просматриваю HeadHunter, Linkedin и множество других ресурсов для поиска на предмет IT специалистов разного толка.
Находясь по ту сторону HeadHunter’а, не перестаю удивляться изобретательности тех, кто находится в поиске работы.
Предлагаю поговорить о том, как эффективно позиционировать себя на рынке труда.
Правильное продающее резюме это первый и главный шаг к работе мечты.
Рекомендации будут практические, проверенные на собственном опыте как со стороны соискателя, так и со стороны рекрутера.

Читая посты на хабре, я заметил, что многие не особо осведомлены как собственно устроен процесс интервью, особенно со стороны работодателя. Также должен отметить, что многие статьи про прохождение интервью имеют немного «пиаристый» характер, и не описывают детали. Хочу восполнить этот пробел, и без воды рассказать, как это работает изнутри.

Все нижеописанное характерно для моей компании, но сам HR достаточно стандартен по калифорнийским стандартам (что сейчас уже практически стало международными стандартами). Никакого пиара, так что просто в двух словах: моя компания — это маленькая транснациональная компания со штатом где-то в 4000 человек, HQ — в Palo Alto, R&D (где я работаю) — Vancouver, BC. Я интервьюирую на позицию в моей команде, которая занимается разработкой web-frontend для встраиваемых устройств (используется Python, C и стандартный HTML-набор).

Общие сведения

Это вторая часть статьи, иллюстрирующие возможности использования OS Mikrotik, в качестве HotSpot точки. В первой части я рассказывал как настроить HotSpot, а так же познакомил с возможностью выдачи и покупки карт доступа. Ознакомиться с первой частью вы можете здесь.

После написания поста об алгоритме IT собеседования, мы в комментариях обсуждали, что постоянно кому-то нужно что-то доказывать, выполнять глупые тестовые задания и т.д. Область, в которой мы работаем, растет и развивается очень быстро. Классические институты не успевают менять свои программы, да и преподаватели уже не в курсе происходящего.

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

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



Итак, всех заинтересованных — прошу под кат.

Мой рассказ будет состоять из трёх частей.

1 часть. Заземление
(общая информация, термины и определения)

2 часть. Традиционные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

3 часть. Современные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

В первой части (теория) я опишу терминологию, основные виды заземления (назначение) и предъявляемые к заземлению требования.
Во второй части (практика) будет рассказ про традиционные решения, применяемые при строительстве заземляющих устройств, с перечислением достоинств и недостатков этих решений.
Третья часть (практика) в некотором смысле продолжит вторую. В ней будет содержаться описание новых технологий, используемых при строительстве заземляющих устройств. Как и во второй части, с перечислением достоинств и недостатков этих технологий.

Если читатель обладает теоретическими знаниями и интересуется только практической реализацией — ему лучше пропустить первую часть и начать чтение со второй части.

Если читатель обладает необходимыми знаниями и хочет познакомиться только с новинками — лучше пропустить первые две части и сразу перейти к чтению третьей.

Мой взгляд на описанные методы и решения в какой-то степени однобокий. Прошу читателя понимать, что я не выдвигаю свой материал за всеобъемлющий объективный труд и выражаю в нём свою точку зрения, свой опыт.

Некоторая часть текста является компромиссом между точностью и желанием объяснить “человеческим языком”, поэтому допущены упрощения, могущие “резать слух” технически подкованного читателя.

Один мой товарищ недавно активно искал работу, и спрашивал меня, как себя подавать перед работодателем. Погуглив, мы пролистали с десяток статей о том, как надо и как не надо делать во время поиска, и одну из них я решил перевести для хабрасообщества, возможно кому-то это поможет избежать ошибок, которые в ней описаны. Манера статьи довольно провокационная, язык местами нецензурен, поэтому я постарался сгладить углы. Итак, поехали..

На любом околосетевом форуме легко найти с десяток веток о выборе оборудования для BGP-пиринга с возможностью «держать две, три, пять, двадцать пять фулвью». Большинство таких веток выливается в холивары на тему Cisco vs. Juniper или еще чего похуже. Офлайновое же их развитие нередко напоминает мультфильм о шести шапках из одной овичины. В общем, бывает смешно.

И крайне редко обсуждается вопрос о необходимости этого самого фулвью.

Что из себя представляет руководство на самом деле, или каким оно должно быть?
К сожалению в наших реалиях хороший руководитель — большая редкость. Возможно, некоторые мысли помогут некоторым «свежеиспеченным» руководителям не наступить на старые ржавые грабли. Тем кто не связан с руководством — поможет понять в чем заключается работа руководителя. А, умудренные руководящим опытом, я надеюсь, выскажутся в комментариях, и поделятся своим опытом.

В этой статье не пойдет речи об организации процессов. Здесь будет затронута только тематика рабочих взаимоотношений.

Эссе Джоэля Спольски (Joel Spolsky) о мотивации, о денежных премиях и о том, что делать с сотрудником, если его идея принесла вашей компании миллион долларов. Оригинал статьи на английском языке можно прочитать здесь.

Джоэль Спольски — один из создателей сайта stackoverflow.com и ведущий блога joelonsoftware.com.

Два года назад студент по имени Ноа Вайс (Noah Weiss), проходивший летнюю стажировку в нашей фирме Fog Creek, поделился со мной отличной бизнес-идеей. Он обратил мое внимание на то, что довольно много сайтов IT-тематики размещают платные объявления о вакансиях, и предложил мне делать то же самое на страницах моего блога Joel on Software. По словам Ноа, написать систему показа таких объявлений будет проще простого («Это же просто еще одна таблица в базе!»). А для других продуктов у нас уже были готовые модули для приема банковских карт и генерации платежек, так что проект действительно выглядел несложным.

Но я колебался. До этого я не размещал рекламу в своем блоге, и, честно говоря, вовсе не планировал переводить его в коммерческое русло.

Долгое время все большие проекты, связанные с сетью, будь то web-проект или ДЦ крупного предприятия представляли собой одну и ту же структуру. Это была характерная древовидная архитектура, различающаяся лишь размером дерева и плотностью «ветвей», обусловленных разными требованиями к надежности и производительности. Но цифровой мир не стоит на месте, а стремительно растет и развивается, при чем не только в увеличиваясь объемах и скоростях, но и меняя свою структуру. Всевозможные Big Data, облака и распределенные вычисления привели к тому, что по сети стало необходимым передавать огромные объемы данных между большим количеством конечных узлов, причем, желательно, с минимальной задержкой.

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