Представляю вам серию из двух постов, где я постараюсь рассказать о разработке довольно типового решения VDI для предприятия среднего размера. В первой части – подготовка к внедрению, планирование; во второй – реальные практически примеры.

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

Например, у одного из заказчиков, крупной отечественной софтверной компании, имеется довольно большой парк серверов и систем хранения. В том числе — несколько серверов HP ProLiant 6-го и 7-го поколения и система хранения HP EVA, которые были в резерве. Именно на их базе нужно было разработать решение.
Озвученными требованиями к решению VDI были:

• Floating Desktops Pool (с сохранением изменений после окончания сессии);
• Начальная конфигурация — 700 пользователей, с расширением до 1000.

Мне предстояло просчитать какое количество серверов и систем хранения в итоге перейдут из резерва в состав решения.
В качестве среды виртуализации выбрана VMware. Схема работы получилась примерно такая:

С приходом облачных технологий утопичная идея «иметь доступ к чему угодно, откуда угодно, с чего угодно» стала постепенно воплощаться в реальность. Всего за несколько лет понятия «частное облако», VDS, VDI и т.п. стали массово употребимыми – не без участия маркетологов практически всех крупных международных вендоров. Тем не менее, до сих пор существует определенная путаница терминов и понятий на рынке, а также ряд «неустаревающих» вопросов. Например, что такое виртуализация десктопов? Это технология или подход? В чем отличие виртуализации десктопов от инфраструктуры виртуальных рабочих столов? Наконец, при чем здесь Dell? За ответами на эти и другие вопросы просим под кат.

Конечно подобный пост найдет голосовательное одобрение только в пламенных сердцах ИТ-подрядчиков, и бойцов прифронтовой кибернетической полосы — но думаю опубликовать будет не лишне!

Работаю АйТишником в крупной компании. В общем, все нормально и замечательно. Как-то однажды наше руководство решило идти в ногу со временем и возникли мысли автоматизироваться. Выбирали довольно долго Электронный документооборот, но либо денег жалко было много платить, либо разработчики какие-то липовые, короче, времени заняло все это переговорно-презентационное безобразие предостаточно. В конечном итоге остановились на некотором решении. Продукт адекватный, разработан под Microsoft Sharepoint 2013 Worklite Docs (я в силу некоторых обстоятельств с этой системой хорошо знаком). В общем выбор пал на него.

Мы собрали воедино все наши корпоративные хотелки, заказали, внедрили — запустили. Все нормально, все работает. Но суть не в этом. Это была присказка.

Есть замечательная статья, в которой рассказывается, как это делается на Cisco. Но мы не хотим тратить $100500 на приобретение штампованных оттисков «Cisco Systems» на корпусе маршрутизатора.

Описание проблемы

Итак, суть проблемы: имеется два NAT через двух разных провайдеров, локальная сеть, в которой есть сервер и который должен быть публичным и доступным через оба NAT. У провайдеров разные приоритеты: сначала задействуется первый, потом второй.

Если пакет вошёл через первого провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера и уходит туда, откуда пришёл первый пакет. Хорошо.

Если пакет вошёл через второго провайдера, он NAT-ится на наш сервер, обрабатывается, образуется ответный пакет, который выходит через первого провайдера… а почему? Потому, что сначала в Linux происходит маршрутизация, а потом уже SNAT. Итак, при маршрутизации пакету назначается следующий узел — шлюз первого провайдера (по умолчанию). Потом происходит отслеживание соединения — conntrack замечает, что этот пакет является ответом на другой, и заменяет адрес отправителя адресом, который выдал нам второй провайдер. А потом пакет направляется через интерфейс первого провайдера на его шлюз. Как правило, провайдер блокирует пакеты, адресом отправителя которых указан адрес не из их подсети. Плохо.

Я – ваш новый технический директор.

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

Профессионалы ли мы?

Это главный вопрос. Я расскажу, чего я от вас жду, и это определит ответ на вопрос, профессионалы ли мы.

Как часто ты сидел на совещаниях, которые, перевалив по длительности за 2 часа, пытались решить одновременно все проблемы на свете? Когда люди, красные от духоты, теряя самообладание от усталости, начинают пытаться перекричать друг друга в попытке найти правильное решение? Когда каждое совещание кончается ничем, а все участники клянутся себе, что больше никогда снова не соберутся на эти бессмысленные встречи?

Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен Active Directory: «О, уж теперь-то все будет как следует!» Ан нет, домен потихонечку разрастается, создаются новые учетки, блокируются старые, добавляются, удаляются компьютеры, девушки выходят замуж, меняют фамилии и, в конце концов, база данных службы каталогов выглядит, как полный швах. В этом топике мы наладим связь между базой Active Directory и кадровой системой предприятия, а также создадим механизм для поддержания данных сотрудников в AD в актуальном состоянии.

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

Для написания этой заметки  было затрачено:

• 68338 километров на поездки.
• 72 человеко-часа на почтовую переписку.
• 423 человеко-часа на эксперименты с коллективом в 30 человек.
• 88 часов на подготовку докладов и выступления на конференциях.
• 17 чашек кофе на беседу с мудрыми людьми на афтепати.
• Порядка 25 часов на набор этого текста и правку багов в нем :).
• До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.

Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!

Ну, логично же, что:

• Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
• Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.

А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

В ноябре 2012 в МГТУ им. Баумана мы, Школа системного анализа,
провели открытое событие «Введение в профессию системного аналитика».

Наконец стала доступна первая часть видео, выступление
Сергея Нужненко на тему «В чём заключается работа системного аналитика»:

1. Мифы о задачах и ответственности. Смежные роли (5 минут): vimeo.com/61652862​

2. Риски и неопределённость. Место и задачи в проектном цикле (18 минут): vimeo.com/61968936

3. Окружение, предмет и модель работы. Типовые процессы (10 минут): vimeo.com/62449309

4. Аналитический цикл работы с информацией. Модальная логика (12 минут): vimeo.com/64330992

Продолжаем переводить книгу о унифицированной системе IT-мониторинга. После интриги с вопросами, автор начинает на них постепенно отвечать.

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

Итак, Глава 2. О том, что предпринять, чтобы информация не была разрознена. Для тех, кто уже пользуется системами мониторинга многие вещи покажутся знакомыми.

Продолжаем перевод. В этой главе разговор пойдёт о организации сервис-деска и способах построения взаимодействий с пользователями, а также получении от них обратной связи. Увидим почему 'хорошо' с точки зрения ИТ, не всегда означает 'хорошо' с точки зрения пользователя и как можно уравновесить эти две оценки.

Думаю многим известна особенность PostgreSQL, которая приводит к эффекту раздувания таблиц, или table bloat. Известно что она проявляет себя в случаях интенсивного обновления данных, как при частых UPDATE так и при INSERT/DELETE операциях. В результате такого раздувания снижается производительность. Рассмотрим почему это происходит и как с этим можно бороться.

Решил написать, так как в основном есть статьи по резервированию основного 3g канала на другой, а 3g как резервный при проводном интернете — почему то сложно найти.

Была поставлена задача организовать людям резервирование доступа в интернет с автоматическим переключением канала.

Покопав интернет, были найдены устройства с поддержкой 3g «свистков». Выбор был из Zyxel Keenetic, drytek и TP-Link (но всю жизнь работали с Asus и D-Link по объективным причинам и собственным статистическим данным). По опыту решения «всяких» задач, выбор пал на TP-Link. Выбрать было просто, Open WRT дружит со всеми TP-Link'ами (запасной вариант). Так же требования по 3g связи. Предоставили мне Huawei E367 от мегафона.

Коробка попала ко мне в руки. (описывать ее не буду, описаний много, сразу к делу). Приятные плюшки от TP-Link'а радовали всегда. В «поле» он у нас ни когда не тестился. Работа всегда велась с более стабильными роутерами. Но Open WRT в данном вопросе — перевесил все сомнения. И как оказалось — не зря, но об этом позже.

Базовая прошивка, базовая настройка, Wan preffered, запуск, тест. Эмуляция «сетевой кабель не подключен» работает на ура. В обе стороны как надо переключается канал. Но мы то знаем, что «падения» бывают не только на «крыше», но и дальше. Кто то что то копал, задел кабель, порвал. Свитч жив, линк по кабелю жив, роутер «думат» что всё ок. Нас это не устраивает.

Задача:
1) TP-LINK TL-MR3420 V2
2) 3g интернет Мегафон Huawei E367
3) Провайдер с настройками по Static IP и проводом с RJ-45

Вступление

Всем доброго времени суток! В этой статье я хотел бы еще раз поднять тему защиты персональных данных (далее будем обзывать их — ПДн), а также тему защиты от регуляторов. Пик дебатов на тему защиты ПДн давно прошел. Приходились эти пики как правило на приближение очередного «самого последнего срока» ввода 152-ФЗ в полную силу. В итоге «самый последний срок» наступил, активные дебаты стихли, но закон «О персональных данных» живет, регуляторы устраивают проверки и наказывают нарушителей. Поэтому тема будет еще долго актуальна.

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


Типичный пример разглашения ПДн специальной категории (сведения об интимной жизни)

Все чаще приходится слышать: "Работай на результат!"

"Работай на результат!" — кричит начальник подчиненному, чтобы заставить этого тупого неповоротливого кретина, принятого в команду по протекции, приносить хоть какую-то пользу общему делу.

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

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

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

Культ карго. Мало кто из произносящих эту фразу может внятно объяснить, какой смысл в неё вкладывается. Люди верят в неё, как в волшебную формулу, заклинание, они пихают её куда ни попадя, надеясь, что она придаст им уникальность, выделит их из толпы таких же неудачников. Организации, Компании, конторы да и откровенные «шараги» не мыслят себя без этого лозунга. Как же это, «Рога и копыта» работают на результат, а мы, что, хуже?



А хуже ли?

Что такое хелпдеск? Система управления заявками пользователей, личинка сервисдеска, первый шаг эникейщика на пути к ITIL, бла-бла-бла…



Литература, посвященная вопросу организации системы управления инцидентами (заявками пользователей, проблемами в ИТ — называйте, как хотите) делится на две категории. Первая включает в себя технические низкоуровневые мануалы, посвященные, в основном, тонкостям настройки конкретных решений. Такие работы могут рассказать в подробностях, как добиться прироста производительности в WonderDesk величиной 0.001% под SuperSQL v.0.0001 alpha, но, как правило, ничего не говорят о том, зачем вообще нужен этот WonderDesk, и, главное, что с ним, существенно ускоренным, потом делать.

Вторая категория написана для… Даже не знаю, для кого. Я бы сказал, что для богов, но им, вроде, инструкции не нужны. «Нужно пересмотреть саму парадигму взаимодействия паттернов бизнес-процессов в рамках концепции корпоративных ценностей с целью повышения уровня зрелости...» Ага, пересмотрел (предварительно подглядев в словаре значения всех этих непонятных слов), дальше что? Как сделать, чтобы мое «пересмотренное понимание» заставило пользователей писать заявки, эникейщиков — обрабатывать их, а уровень зрелости — повышаться?! Предлагаете «постепенно внедрять лучшие практики управления»? Да, как же их внедрить, если я простой эникейщик и ничем не управляю?!

Остается одно — пытаться действовать «по наитию». О двух таких попытках, о том, как именно они предпринимались, какие имели предпосылки, к каким привели результатам, т.е. о практическом опыте внедрения хелпдеска в условиях агрессивной враждебной среды, и будет рассказано в этом топике. Надеюсь, он хоть немного заполнит образовавшийся пробел, предоставив эникейщикам и низкоквалифицированным админам сведения о том, как из состояния A, когда о хелпдеске и речи быть не может, перейти в состояние A', когда этот хелпдеск уже внедрен и работает.

Так уж сложилось, что последние несколько лет я занимал самые разнообразные руководящие должности в полудюжине компаний, занимающихся разработкой программного обеспечения разного рода. Довелось побывать и тимлидом, и менеджером проекта, и группы проектов, руководителем отдела и руководителем технического направления; подопечных бывало от двух до ста пятидесяти человек, да и размеры компании варьировались от трёх до двухсот тысяч работников. Неизменным оставалось только одно: чисто управленческая работа, постепенный и окончательный отход от технических задач.

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Эпиграф: Зарплата у меня хорошая, но маленькая!

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

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

Это перевод нашумевшей статьи с TechCrunch от Джеймса Альтушера — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу. Читайте его в Twitter @jaltucher.

Люди читают TechCrunch потому, что они хотят что-то создать, они не желают следовать приказам всю жизнь и хотят финансовой свободы. Давайте начистоту. Эти три пункта кажутся притягательными. Да благословит Вас Бог. Надеюсь, что когда Вы их обретете, Вы сможете сохранить их. Большинству людей (например, МНЕ), нужно просто немного покататься на американских горках, потому что мы тупые. Но некоторые люди умные.