Тогда возникает резонный вопрос — «почему»? Если это экономически эффективно, почему на комбайн не садят 2-3 операторов, как в танк? Один ведет комбайн, второй стреляет хоботом, третий смотрит за параметрами уборки и теми двумя интилихентами?
Опять понесло. Я не хочу сказать, что всем нужно самим бросаться к капитану или за борт (предварительно открыв кингстон). Но встать перед этим выбором, в кризис, намного вероятнее.
Так себе идея в кризис. Может статься, что идти некуда. А туда куда можно, царит такая же атмосфера.
Все это уже было, и не раз. Замечательная книга на эту тему — гроздья гнева. Понятно, у нас пока не великая депрессия, сегодня. А завтра?
По опыту преодоления предыдущих кризисов я замечал строго противоположное тому, что написано в статье. Если кратко — внутри выживают самые приспособленцы. Типа, в шторм капитан должен быть уверен в каждом матросе, а кто и что по факту делает, с мостика не видать. Вот Вася, глаза горят, шерсть дыбом, готов капитана в жопу целовать (а чаще уже и целует) — это правильный матрос. А вот Федя ходит злой как черт, и все время что-то пропадает в трюме. Это плохой матрос, что у него на уме? А то, что Вася ничего не делает кроме подношения рома и целования, в отличие от Феди который в трюме ручной помпой борется за живучесть, как я уже говорил, с мостика не видать. И когда Федя идет к капитану с предложениями, образ его уже сформирован. И не без участия Васи, Федя с его предложениями идет за борт. Что будет с корблем — а как повезет, смотря сколько этих Федь еще осталось. Какова везучесть капитана и пр. факторы. Но факт, что Вася, если переживет с судном шторм, поднимится в ранге и уже сам будет нанимать новых Федей за мелкий прайс.
Хм… На первое место, по моему опыту, я бы вывел установка корректных драйверов внутри винды и пакета qemu-ga-tools. Прям по инструкции, стандартные драйвера, то как это видит себе винда — минус 100500 к производительности.
Второй момент, разобраться с memmory overcommit и Ballooning, это позволит не лезть лишний раз к дисковой подсистеме за счет перераспределения памяти и снижения swap.
Ну и в третьих надо смотреть что выведено в качестве гостевых систем. Если у вас там крутится БД с большим IO, её надо вытаскивать в отдельный сторадж, чтобы все остальные об нее не запинались.
Вообще измерять что-то изнутри ВМ это странно до неприличия. Смотреть в первую очередь надо со стороны KVM. Может быть, что вы упираетесь в ресурсы контроллера и массива, например, за счет не верного модуля-драйвера на контроллер. Тип файловой системы и параметры журналирования. Нагрузка от типа операций (чего больше, чтения или записи). Чем вызваны потребности в этих операциях?
Эххх, хотел продолжить свой цикл статей, но руки так и не дошли. Может в карантине продолжу.
Как мне кажется, сравнение ИТ с медициной не очень удачно. Медицина очень консервативна, это не хорошо и не плохо, это так сложилось. У этого качества есть положительная черта — пациенты меньше страдают от недоработок функционала (хотя тоже спорный тезис). Но есть и отрицательная — невероятная сложность изменений и вывода новых методов лечения и препаратов. Я лично знаю один прецедент, когда лекарство разработанное изначально для скота не стали сертифицировать для людей. По причине запредельности бюджета и сложности процедур. Хотя в использовании на животных оно показывало хорошее действие.
Скорость вывода инноваций в ИТ несоизмеримо больше, чем в медицине, цена риска (в целом, не берем узкие ниши типа самолетостроения) ниже. Каждый подход имеет свои ограничений и хорош для своей области.
Ну а техническим аспектом в моей истории бы являлось, что мы перевели в 2008 году все агенство, кроме бухгалтерии и топ-ов на линухи. Настроили перемещаемые профили, сделали доменную авторизацию, внедрили систему централизованного управления SpaceWalk и кучу разных полезных вещей. А потом до жилищки добрался кризис и «денежных мешков» не стало, и стали отказывать в ипотеке банки. И вроде город большой, люди рождаются, умирают, женятся, разводятся и клиенты в агентство пишут и звонят. А внутри агенства зарплату депонируют и оставшиеся деньги спускают в проекты по отслеживанию использования рабочего времени при работе на ПК, системы записи разговоров и прочие решения, не устраняющие причину болезни.
PS Ну а цимес ситуации был тот, что в этой компании я был простым админом.
Не отвечу за feddorra, могу рассказать про себя. Статья мне понравилась тем, что хорошо иллюстрирует на примере истину, что не все проблемы решаются техническими методами. Более того, данная статья очень хорошо ложится в контексте обсуждения статьи «Нюансы современной медицины», в части лечения симптомов и глубины анализа при принятии решения о направлении лечения.
Я сам участвовал в подобном аттракционе. Краткая история — агентству недвижимости выгодно иметь постоянный поток клиентов, а риелтору выгодно иметь с этого потока денежку. Казалось бы цели совпадают, но тут возникает нюанс: риелтор может заработать на прямой продаже (приехал человек с чемоданом денег) или с помощью цепочек купли-продажи из нескольких участников (3-5-7). Прибыль конкретного риелтора отнесенная к потраченному времени, в обоих случаях, примерно одинакова, но есть существенная разница в трудозатратах. И риелторы начинают «сливать» клиентов (не заносить заявки в CRM), когда выясняют, что к ним обращается не вожделенный чемодан с деньгами. Поскольку кто обращение занес, тому в работу оно и назначалось. Потерю клиентов руководство пыталось решать техническими способами (уведомления во весь экран о входящей почте, записью и выборочной прослушкой всех звонков и пр. пр.). Сколько было потрачено денег и сил на внедрение всей этой автоматизации бардака, никому не известно. В итоге (с моей подачи) наняли 3-х сотрудников внешнего колл-центра, двое принимали весь входящий поток обращений (звонки и почта) и заносили его в CRM и им к з/п платили доп. бонус за количество внесенных заявок. Сформированная в CRM заявка по round-robin назначалась на произвольного риелтора. А третий человек обзванивал клиентов, которые отказались от услуг после общения с риелтором, уточнял и фиксировал причины отказа. Половина недешевой автоматизации стала не нужна, а выручка агентства значительно возросла с лихвой компенсируя з/п трех операторов.
Остапа понесло… Причем, следуя своим правилам при отработке моей рацухи я раскрывал суть вносимых изменений, по сути из шаманства отдавал людям методологию. И тут я лишился главного козыря — чуда нет, это можно легко повторить и без меня. Было бы желание. А значит нет смысла меня удерживать. Не нравится з/п? Ну иди поищи где лучше. Нашел, всем доволен, но и на новом месте вижу сохранение подхода к дойке. Единственный раз когда мои усилия сказывались на кошельке здесь и сейчас, это когда я был участником маленькой ИТ артели по обследованию юр. лиц. Там все было просто — 5 человек, по сути и работники и учередители. Сами пашем, сами пляшем.
Давайте считать, что такой человек — это я? Серьезно, может и не до конца, но стараюсь стремится мыслить такими же категориями. Однако, объективная реальность возвращает меня к сущности рыночных отношений в отдельно взятой стране. И, к сожалению, она звучит так: чтобы корова меньше ела и больше давала молока — ее нужно реже кормить и чаще доить. Я работал в оутсорсе, был наемным рабочим в среднем и крупном бизнесе и не встречал, чтобы не продающим подразделениям выплачивали процента с оптимизаций. Причем, даже в тех случаях, когда эта оптимизация была видна в деньгах сразу и всем. Условно, строили объект за 10n денег, вызываюсь добровольцем с рац. предложением. Применяем мои подходы и строим уже за 8n денег с сохранением сроков и повышением качества. Результат для меня лично — спасибо и включение меня в эту активность на принудительной основе. Когда встал вопрос о повышении з\п был ответ о трудных временах, хотя 1n из экономии с одного объекта — закрыл бы все финансовые вопросы по индексации на год.
Про время восстановления, даже на ssd, с учетом времени на POST, меньше 40сек — минуты мы выжать не смогли.
Вариант с virtualbox мы прикидывали. Но вариант с одним сервером и образом на 4 станции филиала нам понравился больше. Банально, 10 филиалов по 4 машины — 40 точек контроля.
Если переложить функционал рабочего места на сервак, удобно поддерживать винду в актуальном состоянии, на золотой образ накатил обновы, протестировал, разлил на 10 серверов и забыл. Тоже и с прикладным ПО, захотят завтра еще какую-нибудь софтину, поставил и разлил.
Да и производительность у KVM на порядок лучше чем у virtualbox. Ну и memory overcommit на сдачу.
Он, вроде как, был только в альфе. На полном дистрибутиве его выпилили. Но главный момент был в боязни вирусни. На флешках нам тянут гадости тонны. Хотелось гарантий, что ни одна зараза не переживет перезагрузки.
Срок редактирования комментрия истек. Я его перечитал и сам себя не понял.Имеется в виду, в случае локального восстановления первоначального состояния системы, скорость работы нам не понравилась. В случае (недо)VDI вся работа по перезапуска VM происходит в фоне и на времени ожидания начала работы клиентов с сервисом, не сказывается.
Обязательно посмотрю, поиграюсь. Мы сознательно упрощали схему. Хотелось штуку простую как лопата, устойчивую к отказам электроснабжения и с низкими трудозатратами по сопровождению.
Скажем так, это серебряный призер внутреннего отбора. Не так уж и не гоже, да? От варианта с локальным восстановлением мы и хотели уйти, слишком оно трудозатратное по сопровождению. Обновления как софта, так и системы, в этом случае требует отдельного процесса. В случае, описанном в статье, достаточно ночью разлить новый образ виртуального диска по серверам и готово!
Дык вы ничего и не просили.
Опять понесло. Я не хочу сказать, что всем нужно самим бросаться к капитану или за борт (предварительно открыв кингстон). Но встать перед этим выбором, в кризис, намного вероятнее.
Так себе идея в кризис. Может статься, что идти некуда. А туда куда можно, царит такая же атмосфера.
Все это уже было, и не раз. Замечательная книга на эту тему — гроздья гнева. Понятно, у нас пока не великая депрессия, сегодня. А завтра?
По опыту преодоления предыдущих кризисов я замечал строго противоположное тому, что написано в статье. Если кратко — внутри выживают самые приспособленцы. Типа, в шторм капитан должен быть уверен в каждом матросе, а кто и что по факту делает, с мостика не видать. Вот Вася, глаза горят, шерсть дыбом, готов капитана в жопу целовать (а чаще уже и целует) — это правильный матрос. А вот Федя ходит злой как черт, и все время что-то пропадает в трюме. Это плохой матрос, что у него на уме? А то, что Вася ничего не делает кроме подношения рома и целования, в отличие от Феди который в трюме ручной помпой борется за живучесть, как я уже говорил, с мостика не видать. И когда Федя идет к капитану с предложениями, образ его уже сформирован. И не без участия Васи, Федя с его предложениями идет за борт. Что будет с корблем — а как повезет, смотря сколько этих Федь еще осталось. Какова везучесть капитана и пр. факторы. Но факт, что Вася, если переживет с судном шторм, поднимится в ранге и уже сам будет нанимать новых Федей за мелкий прайс.
Второй момент, разобраться с memmory overcommit и Ballooning, это позволит не лезть лишний раз к дисковой подсистеме за счет перераспределения памяти и снижения swap.
Ну и в третьих надо смотреть что выведено в качестве гостевых систем. Если у вас там крутится БД с большим IO, её надо вытаскивать в отдельный сторадж, чтобы все остальные об нее не запинались.
Вообще измерять что-то изнутри ВМ это странно до неприличия. Смотреть в первую очередь надо со стороны KVM. Может быть, что вы упираетесь в ресурсы контроллера и массива, например, за счет не верного модуля-драйвера на контроллер. Тип файловой системы и параметры журналирования. Нагрузка от типа операций (чего больше, чтения или записи). Чем вызваны потребности в этих операциях?
Эххх, хотел продолжить свой цикл статей, но руки так и не дошли. Может в карантине продолжу.
Скорость вывода инноваций в ИТ несоизмеримо больше, чем в медицине, цена риска (в целом, не берем узкие ниши типа самолетостроения) ниже. Каждый подход имеет свои ограничений и хорош для своей области.
PS Ну а цимес ситуации был тот, что в этой компании я был простым админом.
Я сам участвовал в подобном аттракционе. Краткая история — агентству недвижимости выгодно иметь постоянный поток клиентов, а риелтору выгодно иметь с этого потока денежку. Казалось бы цели совпадают, но тут возникает нюанс: риелтор может заработать на прямой продаже (приехал человек с чемоданом денег) или с помощью цепочек купли-продажи из нескольких участников (3-5-7). Прибыль конкретного риелтора отнесенная к потраченному времени, в обоих случаях, примерно одинакова, но есть существенная разница в трудозатратах. И риелторы начинают «сливать» клиентов (не заносить заявки в CRM), когда выясняют, что к ним обращается не вожделенный чемодан с деньгами. Поскольку кто обращение занес, тому в работу оно и назначалось. Потерю клиентов руководство пыталось решать техническими способами (уведомления во весь экран о входящей почте, записью и выборочной прослушкой всех звонков и пр. пр.). Сколько было потрачено денег и сил на внедрение всей этой автоматизации бардака, никому не известно. В итоге (с моей подачи) наняли 3-х сотрудников внешнего колл-центра, двое принимали весь входящий поток обращений (звонки и почта) и заносили его в CRM и им к з/п платили доп. бонус за количество внесенных заявок. Сформированная в CRM заявка по round-robin назначалась на произвольного риелтора. А третий человек обзванивал клиентов, которые отказались от услуг после общения с риелтором, уточнял и фиксировал причины отказа. Половина недешевой автоматизации стала не нужна, а выручка агентства значительно возросла с лихвой компенсируя з/п трех операторов.
Остапа понесло… Причем, следуя своим правилам при отработке моей рацухи я раскрывал суть вносимых изменений, по сути из шаманства отдавал людям методологию. И тут я лишился главного козыря — чуда нет, это можно легко повторить и без меня. Было бы желание. А значит нет смысла меня удерживать. Не нравится з/п? Ну иди поищи где лучше. Нашел, всем доволен, но и на новом месте вижу сохранение подхода к дойке. Единственный раз когда мои усилия сказывались на кошельке здесь и сейчас, это когда я был участником маленькой ИТ артели по обследованию юр. лиц. Там все было просто — 5 человек, по сути и работники и учередители. Сами пашем, сами пляшем.
Давайте считать, что такой человек — это я? Серьезно, может и не до конца, но стараюсь стремится мыслить такими же категориями. Однако, объективная реальность возвращает меня к сущности рыночных отношений в отдельно взятой стране. И, к сожалению, она звучит так: чтобы корова меньше ела и больше давала молока — ее нужно реже кормить и чаще доить. Я работал в оутсорсе, был наемным рабочим в среднем и крупном бизнесе и не встречал, чтобы не продающим подразделениям выплачивали процента с оптимизаций. Причем, даже в тех случаях, когда эта оптимизация была видна в деньгах сразу и всем. Условно, строили объект за 10n денег, вызываюсь добровольцем с рац. предложением. Применяем мои подходы и строим уже за 8n денег с сохранением сроков и повышением качества. Результат для меня лично — спасибо и включение меня в эту активность на принудительной основе. Когда встал вопрос о повышении з\п был ответ о трудных временах, хотя 1n из экономии с одного объекта — закрыл бы все финансовые вопросы по индексации на год.
Про время восстановления, даже на ssd, с учетом времени на POST, меньше 40сек — минуты мы выжать не смогли.
Вариант с virtualbox мы прикидывали. Но вариант с одним сервером и образом на 4 станции филиала нам понравился больше. Банально, 10 филиалов по 4 машины — 40 точек контроля.
Если переложить функционал рабочего места на сервак, удобно поддерживать винду в актуальном состоянии, на золотой образ накатил обновы, протестировал, разлил на 10 серверов и забыл. Тоже и с прикладным ПО, захотят завтра еще какую-нибудь софтину, поставил и разлил.
Да и производительность у KVM на порядок лучше чем у virtualbox. Ну и memory overcommit на сдачу.
Он, вроде как, был только в альфе. На полном дистрибутиве его выпилили. Но главный момент был в боязни вирусни. На флешках нам тянут гадости тонны. Хотелось гарантий, что ни одна зараза не переживет перезагрузки.
Дополню. Скорость начала работы каждого следующего клиента, с учетом времени на перезагрузку и файловые операции, нас не удовлетворила.