Привет, Хабрачитатели!

В повседневной практике часто нужен набор инструментов – Linux и иногда Windows LiveCD, а также установочные диски различных дистрибутивов. Диски легко подвергаются механическим повреждениям. Учитывая, что набор используемого инструментария и дистрибутивов у каждого не так велик (во избежания развода зоопарка) и зачастую вполне умещается на USB-носителе до 4G, целесообразно поместить все на одну флэшку.
К вашему вниманию флэшка для загрузки Live сборок Linux и Windows и установки дистрибутивов Linux. Подготовлен образ .img, который легко разворачивается при помощи dd. Кому интересно, подробности под катом.

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

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.

Прошло уже достаточно времени с тех времен, когда Ni-Cd и Ni-Mh аккумуляторы безраздельно властвовали в мобильных устройствах, но с самого начала эпохи Li-ion и Li-pol все не утихают споры по поводу того, надо ли «тренировать» эти аккумуляторы сразу после покупки.
Доходит до смешного, в теме обсуждения ZP100 на china-iphone всем новичкам рекомендовали в приказном тоне пройти 10 циклов зарядки-разряда, а только потом приходить с вопросами о аккумуляторах.



Давайте попробуем разобраться, имеет ли такая рекомендация право на жизнь, или это рефлексы спинного мозга (за отсутствием головного, наверное) некоторых индивидуумов, у которых они остались со времен никелевых батарей.

Представляю вам серию из двух постов, где я постараюсь рассказать о разработке довольно типового решения 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. Думаю, что данная статья окажется полезным подспорьем, т.к. не требует от администратора введения никаких дополнительных средств, т.е. по сути – мониторинг штатными средствами.