Расходы на виртуализацию. Краткие итоги

Расходы на виртуализацию – это любимая тема для обсуждения, как только вопрос заходит об этой самой виртуализации. Но следует понимать следующее – мы живем в третьем десятилетии 21 века и основная рабочая нагрузка сейчас виртуализирована.

Нравится, не нравится – но это де-факто новый стандарт. Причем мир все дальше уходит от виртуальных машин и отдает предпочтение контейнерам – LXC, Docker и т.д.

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

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

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

Хотим переносимость между хостами с разными поколениями процессора – миримся с тем, что некоторые современные инструкции виртуалка не поддерживает.

Желаем максимальную производительность – выбираем самые современные синтетические устройства.

Но в любом случае расходы на виртуализацию не должны превышать 10-15%, если более, то вы что-то сделали не так, или сознательно пожертвовали производительностью ради иных преимуществ.

А теперь вернемся к нашим процентам. Ребята, если для вас эти 10-15% являются критичными, то у меня плохая новость – ваша система не тянет рабочую нагрузку и справляется из последних сил.

Откройте любую систему мониторинга и посмотрите пороги срабатывания триггеров по основным показателям. Примерно будет так: 80% - начинаем беспокоиться и принимать меры, 90% - бьем во все колокола, включаем сирену и вообще сигнализируем, что ситуация полный швах!

А это как раз ваши 10-15% «потерянные» на виртуализации. Если так, то ваша система и без виртуализации не имела никакого запаса производительности и любой резкий скачок спокойно выбьет ее из седла, а виртуализация только подсветила проблему.

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

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

Если брать ту же 1С, то это 35-40 «попугаев» по Гилеву. Вы можете станцевать ужом на сковородке и обеспечить 60-70-100!!! Но кто это заметит?

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

Ну было у нас 75 «попугаев» Гилева, стало 65 – кто это заметит? Никто. Но за эти 10 «попугаев» мы приобретаем переносимость, высокую доступность, снижение затрат на сопровождение и многие другие плюшки.

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

858 терабайт государственных данных Южной Кореи сгорели к чёртовой матери. Бэкапа просто не было

26 сентября 2025 года в государственном дата-центре National Information Resources Service (NIRS) в городе Тэджон вспыхнул пожар. За несколько часов огонь уничтожил серверы облачного хранилища G-Drive (от слова government), где чиновникам выделялось по 30 ГБ для хранения различных документов, которые запрещено было хранить на офисных компьютерах. Им пользовалось 17% всех федеральных чиновников в Корее, или около 125 тысяч человек. Но не только — там хранились данные ещё 163 онлайн-сервисов южнокорейского правительства.

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

✅ Подробнее: https://habr.com/ru/articles/954512

В этой новости все прекрасно. И в очередной раз показывает, что госы - такие госы и не только у нас в стране.

Про «реальную производительность» и APDEX

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

Мы специально взяли фразу «реальная производительность» в кавычки, потому что за ней кроется нечто непонятное, которое каждый понимает по-своему. Вот прямо сейчас попробуйте отвлечься от прочтения заметки и попытайтесь сформулировать определение этому термину.

Скорее всего это будет синтетическая оценка в попугаях какого-либо популярного теста. Но если вас тут же спросят – а насколько хорошо будет работать на такой конфигурации некоторое бизнес-приложение вы вряд ли сможете дать точный ответ.

А теперь сделаем некоторое лирическое отступление. IT-отдел подразделение сугубо затратное, прибыли оно не приносит. Его задача обеспечивать бизнес-процессы. Прибыль при этом генерируют совсем другие подразделения.

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

Если пользователи такого подразделения говорят, что система работает плохо, то вы можете до посинения показывать результаты бенчмарков и уверять, что с вашей стороны все хорошо, вон целых 100 попугаев по Гилеву, должно все летать… Ответ будет прост – не летает, пользователи недовольны.

А в соседней конторе может стоять точно такой же сервер, с точной такой же конфигурацией 1С и там все довольны. Это как так? Почему?

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

Основным фактором влияния для APDEX является целевое время выполнения операции, если операция укладывается в период T – все довольны, если выходит за пределы 4T – полностью разочарованы.

Собранные результаты обрабатываются и нормируются по шкале от 0 до 1, где 0 – полностью разочарованы, 1 – полностью довольны.

👉 Результаты интерпретируются по шкале:

▫️0.00 - 0.50 неприемлемо
▫️0.50 - 0.70 очень плохо
▫️0.70 - 0.85 плохо
▫️0.85 - 0.94 хорошо
▫️0.94 - 1.00 отлично

APDEX вычисляется для каждой ключевой операции, что позволяет учесть конкретные потребности бизнеса и особенности его бизнес-процессов.

И именно APDEX даст понимание степени комфортности работы с системой и позволит не просто так крутить показатели, а добиваться именно нужных результатов. А также сразу видеть, какие именно участки требуют внимания.

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

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

Согласны, степень довольства – величина субъективная, но APDEX как раз позволяет сопоставить субъективные ощущения с объективными данными.

Если большинство пользователей говорит, что система работает так себе, то принимаем индекс APDEX за 0,65 – плохо, выясняем реальное время выполнения операции и на его основании рассчитываем желаемое T.

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

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

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

Стоит ли отрицать современные тренды?

Каждый раз при обсуждении виртуализации, контейнеризации и т.п. слышим мнения: мол зачем это нужно у меня и так все хорошо работает…

Начнем с того, что сфера IT во всех ее проявлениях весьма динамична и здесь, как в Алисе: «Нужно бежать со всех ног, чтобы только оставаться на месте»

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

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

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

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

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

Второй бич бюджетки – это отношения «ты начальник – я дурак, я начальник – ты дурак» и связанные с ними бесконечные согласования, обсуждения и т.п. После того, как я ушел оттуда в частную фирму мой новый начальник еще с полгода закрывал лицо рукой и устало произносил: «ну, когда ты начнешь работать самостоятельно???»

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

Появляется определенная зона комфорта. Действительно, а зачем учить что-то новое, если и так все работает? Зачем что-то внедрять, рисковать, тратить время и нервы, когда можно ничего не делать и получать те же деньги?

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

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

В этом случае выясняется, что проще все сломать и построить заново, нежели приводить то, что есть в порядок и вряд ли ваша карьера в этом месте продолжит дальше катиться по накатанной.

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

Это любители ставить в продакшен Gentoo, FreeBSD, Solaris и тому подобную экзотику, прекрасно понимая, что в обозримом пространстве специалистов по этой системе не найти и они вроде как на коне.

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

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

Вот сейчас поиск на HH по слову Linux показывает в Москве 44 166 вакансии, по слову FreeBSD – всего 1 776. И это при том, что коммерческая разработка у нас нацелена на DEB/RPM и нестандартная ОС автоматически означает отсутствие официальной поддержки.

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

Их нравы

Эрик Рэймонд (Eric S. Raymond), один из основателей организации OSI (Open Source Initiative), стоявший у истоков движения открытого ПО, высказался по поводу кодексов поведения:

Я собираюсь сделать то, чего, по-моему, никогда раньше не делал, а именно: использовать весь свой авторитет как человека, который открыл и записал правила открытого исходного кода.

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

Вот мой совет по поводу кодексов поведения:

▫️ 1. Откажитесь от него. Если у вашего проекта есть такой кодекс, удалите его. Единственная реальная функция, которую он выполняет, — это инструмент в руках тех, кто любит подливать масла в огонь.

▫️ 2. Если вы вынуждены иметь такой кодекс по бюрократическим причинам, замените его следующим предложением или чем-то подобным: «Если вы доставляете больше хлопот, чем оправдывают ваши вклады, вы будете отстранены».

▫️ 3.Попытки делать кодексы более конкретными и подробными не работают. Они только дают провокаторам возможность манипулировать.

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

✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=63968

Мне казалось, что этого уже никогда не случится там. Но, оказывается, голос разума пробивается свозь «повесточку».

Потому что ты или приносишь пользу сообществу, невзирая на то, что ты какой-то такой или не такой, или пользы не приносишь, а только суету.

В первом случае ты его уважаемый участник, во втором нафиг сообществу нужен. Вот и всё.

А все эти спекуляции « я не такая, я жду трамвая» оставьте где-нибудь в другом месте.

Что я, что многие мои коллеги исходим из принципа: ты или выполняешь свою работу, либо нет. Соответствуешь квалификации – либо нет. А то, что ты там ешь, с кем спишь, какие у тебя политические и религиозные предпочтения – дело сугубо личное.

Ровно, как и попытки ущемиться по этому поводу. Потому что выгоняют тебя не потому, что ты спишь на потолке, а потому что ты дурак и токсичен. Ничего личного.

Небольшая подборка по дедупликации

🔹 Windows Server. Дедупликация

🔹 Включаем дедупликацию в Windows 10

🔹 Надежность дедуплицированных данных. Небольшое тестирование

🔹 Полностью отключаем дедупликацию в Windows

Стандартное – нестандартное

В комментариях постоянно спрашивают, мол чем не угодила автору FreeBSD, Gentoo и т.д. и т.п. – список можно продолжать. Ну раз спрашивают – отвечаю.

Любая система имеет совокупную стоимость обслуживания – в которую входят как прямые, так и косвенные расходы на ее поддержку в течении всего жизненного цикла. И если с прямыми все понятно, то вот с косвенными не все так просто. Особенно если смотреть с позиции технического специалиста.

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

А риски могут быть разные и простой – один из самых распространенных. Для большинства бизнесов простой – это вполне реальная сумма выручки, которая оказалась не получена из-за невозможности работать. Плюс – возможные репутационные риски – срыв сроков, неисполнение контрактов и т.д. А также прямые и косвенные материальные расходы – просрочка, аренда, зарплата.

К чему все это? А к тому, что в мире сейчас сложились негласные стандарты в очень многих отраслях. Если брать Linux, то там мейнстримом являются два семейства: RHEL и Debian/Ubuntu.

По ним самое большое количество информации, самое большое количество специалистов и основной софт, особенно коммерческий, собирается именно под эти платформы.

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

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

А теперь привезите какую-нибудь экзотику? Скажем, редкого американца и вы узнаете почем фунт лиха. Когда запчасти только под заказ, чинить никто не умеет и вы остаетесь один на один со своими проблемами.

В нашей отрасли все точно также. Вы лично можете быть фанатом чего угодно: FreeBSD, Gentoo, Arch, да хоть Haiku. Но при этом вы должны понимать, что в производственной среде вам требуется более предсказуемое окружение.

Я не даром выбрал именно это слово – предсказуемое. Потому как часто слышал, ну мол что ты, не можешь поставить в _____ (название впишите сами) DEB/RPM пакет?

Могу, но не хочу. Потому что я не могу гарантировать его работоспособность. А следовательно моя среда является непредсказуемой.

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

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

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

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

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

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

Как быстро можно найти администратора на нужном уровне, знающего FreeBSD? Намного сложнее, чем администратора DEB/RHEL. Точно также сложно будет найти и внешнего подрядчика за приемлемую стоимость.

Ну и напоследок стоит подумать о собственной позиции на рынке труда. Да, быть нишевым специалистом – это в чем-то круто. Только надо еще найти того, кому вы сможете продать свою крутизну.

Скажем, Вася в совершенстве владеет плетением лаптей, но кому сейчас это надо?