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

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

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

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

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

Последнее время я очень часто натыкаюсь на перепост статьи о том, как плохо людям работать в больших компаниях. Стоит кому-то запостить эту ерунду, как тут же набегает толпа недовольных хомячков и начинает вопить о том, что всё это правда и большие компании отнимают у них лучшие годы жизни, не давая ничего взамен. Всякий раз, когда я это вижу, у меня в голове возникает одна простая как тапок мысль: «Найди другую работу, тудыть тебя через коромысло!» Если я имею неосторожность озвучить эту мысль, мне обычно возражают, что все компании одинаковы, всё плохо, и вообще, 4 мая 1925 года Земля налетит на небесную ось.
Что ж, позвольте представить вам несколько иной взгляд на вещи. Мне 25 лет, и я работаю рядовым инженером-программистом в крупной компании, название которой не разглашается в интересах следствия. В этой небольшой статье я пройдусь горячим утюгом сатиры по каждому из пунктов оригинальной статьи, и объясню, почему это полный буллшит. Большинство примеров будет являться описанием реальной обстановки в нашей компании.

Привет, ребята!

Спешу поделиться хорошей новостью: мы открыли классное место, а именно коворкинг, «Рабочая Cтанция» в Парке Горького. «Рабочая Cтанция» — это далеко не первая наша вариация на тему коворкинга. И, похоже, теперь нам удалось создать то пространство, о котором мы давно мечтали.

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

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

Это шаблон описания сути вашей компании или проекта в одном предложении. Я открыл его для себя во время стажировки в США. Составив его, мы реально становимся сильнее. В последствии мне это помогло выбрать правильный курс, сфокусироваться и расставить приоритеты.

Я в своей жизни неоднократно сталкивался с тем, что многие в ИТ не видят и не понимают разницы между пользователями (users) и клиентами (customers). Думаю, будет полезно прояснить этот момент в небольшой статье, хотя для многих тема, которую я попытаюсь раскрыть, будет очевидной. Итак, приступим. Готовы?

Введение

Многие интересуются Full-Mesh (или P2P) VPN, хотят использовать их для игр с друзьями, для связи удаленных офисов, серверов, да для чего угодно. Обычные VPN, вроде OpenVPN или PPTP, пропускают весь трафик через центральный сервер, а Full-Mesh соединяются непосредственно с нодами, зачастую пробивая NAT.

От переводчика. Занимаясь созданием и внедрением системы электронного архива, мы не раз сталкивались с ситуациями, когда организации вводят документы в систему без разбора, не уделяя должного внимания экспертизе их ценности. Об этом уже писали. В обсуждениях наших предыдущих публикаций по данному вопросу большинство участников отстаивали следующий взгляд: сохранять можно всю поступающую информацию, она в любой момент может пригодиться. Насколько обоснован такой подход в масштабах крупной организации. Что дешевле и эффективнее: сохранять все, что возможно сохранить — или же грамотно управлять информацией, своевременно удаляя все ненужное? Любопытную статью на эту тему мы нашли в блоге Джорджа Парападакиса, ECM-специалиста из компании IBM. Ее перевод мы и предлагаем вниманию наших читателей.

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

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

Доверие — это большой дефицит в современном мире, уверен, что вы согласитесь с тем, что его приобретение и сохранение важно и в IT, и в бизнесе вообще, и в завоевании желанного сердца.

Случалось ли вам встречать недоверие и нелогичные — казалось бы — отказы со стороны клиентов? Мне – да, и ниже я расскажу, почему они возникают, и как я с этим пытаюсь бороться. Будет замечательно, если вы в комментариях расскажете о своих методах борьбы. Подчеркну: сейчас мы говорим о предложении тех услуг, которые на самом деле необходимы клиенту, а если вы умеете бороться с возражениями, продавая купоны МММ, ваш опыт здесь не совсем применим (хотя в жизни он, может быть, вдвое полезнее).

Проработав несколько лет в небольших web агентствах, 5 месяцeв назад я решил попробовать что-то новое и устроился в довольно крупную (3500 сотрудников) IT-компанию. То, что я увидел на новом рабочем месте, оказалось очень далеким от моих ожиданий. По многочисленным просьбам моих друзей и в ответ недавней статье под катом несколько наблюдений о различиях между большими и маленькими IT компаниями. На вкус и цвет, как известно, фломастеры разные. Так что эта статья — далеко не истина в последней инстанции, это то, с чем я столкнулся и что было для меня важным.

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

Под катом будут финансовые методы, опробованные на ИТ-проектах, в частности — как составить дорожную карту, как работать с горизонтом планирования, как подсчитать показатели, как проанализировать риски.

Сегодня начал работу новый проект Amazon Glacier: долговременное хранилище в облаке по невысокой цене $0,01 за 1 ГБ в месяц. Идеально подходит для хранения бэкапов и больших архивов, к которым не нужен частый доступ. Извлечение данных из Glacier занимает от 3,5 до 4,5 часов.

Как везде в AWS, пользователь оплачивает только тот объём ресурсов, которые реально использует, никакой абонентской платы. Загрузка и извлечение архивов, мониторинг статуса возможны через Amazon Glacier APIs. Все файлы автоматически шифруются AES 256 и дублируются в разных дата-центрах, прежде чем APIs возвращают ответ SUCCESS.

Если есть лекарство, то вам не о чем беспокоиться. Вам достаточно принять его. Если же лекарства нет, то к чему беспокойство? Беспокойство лишь усугубляет страдания. Далай Лама

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


Иллюстрация: ladyiris.ru

Хочу сразу предупредить, что в тексте много букв, но если вам интересны методы борьбы с беспокойством, не поленитесь прочитать его до конца.

Моя статья будет представлять собой больше набор историй из жизни и некоторые выводы из них. Основная проблема, которая меня сейчас волнует: как сделать так, чтобы довольны были и заказчики, и разработчики, и прибыль была и карма цела. Конкретного окончательного рецепта у меня нет, есть несколько отрицательных примеров и намеченные цели, которыми хочется поделиться.
Я занимаюсь разработкой с 2003 года (в основном web-приложения), до этого 4 года преподавала в ОмГУ основы программирования для 1-го курса математического факультета. На данный момент у меня пошел 3-й год в роли совладельца собственной небольшой аутсорсинговой компании. Рассказывать буду исключительно о своем опыте по двум причинам: я успела побывать в трех различных типах компаний, которые могу сравнить, и считаю, что пересказ чьего-то опыта не дает полной картины.

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

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

Что делать? С какой стороны подойти к проблеме? Ниже представлен набор советов и практик, которые нам помогают справиться с этой проблемой. Сначала более общие слова, а потом конкретные методики. В общем-то ничего сверхъествественного, но кому-то может помочь.

Начну серию публикаций по мониторингу Active Directory.
В данных статьях я приведу самые основные проблемы и пути их решения. На основе этих данных функционал легко расширяется до тех требований, которые Вам необходимы.
Учитывая, что сейчас для всех ОС, начиная с Windows Server 2003 R2 и Windows XP SP3 доступен Powershell. Думаю, что данная статья окажется полезным подспорьем, т.к. не требует от администратора введения никаких дополнительных средств, т.е. по сути – мониторинг штатными средствами.

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

В этом повествовании я бы хотел описать свой собственный опыт в области домашней автоматизации на уровне любителя. В своих экспериментах я столкнулся с довольно простыми в использовании системами HomeMatic и X10, применение которых и хотел бы здесь затронуть.
В новостях часто появляются сообщения, что можно управлять чайником или новогодней гирляндой с iPhone (причем обязательно с iPhone, а то новость не будет понята воспринята массами). При этом у меня каждый раз появляется негодование: ну почему люди так бурно реагируют на такие сообщения? Ведь уже давно существуют решения, которые позволяют это сделать. При этом управлять домом из любого браузера, и да… с iPhone тоже!


WebFront

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



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

Ниже – советы, как определить, пора ли переходить на эту технологию или еще нет.