Комментарии 49
Вроде все верно, но в итоге можно столкнуться с оттоком кадров, так как в условном другом месте будет банально комфортнее работать не крохоборствуя :) Отдельный вопрос различные критические ситуации под которые делается большой запас, возможно переплата сейчас выгоднее чем попытки решить проблемы потом
То есть ИТ конечно могут стоить меньше, но едва ли будут
То есть тем, что "возможно" в каком-то ограниченном числе случаев, мы оправдываем большой запас во всех случаях? Это же прямо когнитивное искажение
Смотря с чьей точки зрения смотреть, с точки зрения работника - пусть будет запас, это добавляет уверенности в работе. И я немного о другом - большинство компаний готово (возможно пока) предоставлять этот запас. То есть экономия здесь и сейчас может аукнуться во многих случаях
И отдельный вопрос, кто будет проводить грань между необходимостью и излишествами? Как показывает практика подход эфф. манагеров равно как и только хотелки работников не очень эффективны
И по поводу переплат, вы сравниваете проценты на чем можно сэкономить, но как это влияет на общие затраты отдела разработок? Условно если все это вместе сэкономит полпроцента, то зачем?
Какого работника, какой запас, чего? О чем имею в виду я - у работника есть и запас и быстрая скорость работы.
Тут я согласен, если доходы генерируются приличные, то сделать работникам приятно купив более быстрое железо возможно, однако если мы подходим более рационально, то и требования к срокам обновления железа возрастают. И должен же админ иметь возможность играть в современные игры, в качестве доп.мотивации к зарплате?😄
Но если, у нас сжатый бюджет и мы экономим там и сям, то отличное решение, собственники будут рады повысить немного маржинальность бизнеса.
Крохоборстовать - имба, если запускаете стартап за 29 серебряников с товарищами, чтоб не улететь в долги.
Лишние сервера, «одна задача – один сервер», не консолидируют - 66%
Лишние потери машинных ресурсов при всеобщей виртуализации, VDI, микросервисах. Бывают случаи, когда можно уверенно от них отказаться и не раздувать под них инфраструктуру!
пункты противоречат друг-другу.
>Вместо локальной инфраструктуры - из принципа, мода такая - всё в облака, в ЦОДы - отказываемся - 100%
от ойтишнегов отказываемся - 100%
пункты противоречат друг-другу.
Только на поверхности. Написал же "всеобщей". А в это вкладывается смысл, что высоконагруженные сервисы вроде 1С работают медленнее, чем могли бы на голом железе. И из-за чего возникают "хотелки" собрать сервер с максимальными на данный момент времени характеристиками, что приводит к многократному удорожанию последнего. Также, консолидировать в одном контексте безопасности можно внутри одной ОС. Но при увлечении виртуализацией ради виртуализации, для каждой задачки гоняется отдельно целая ОС, под которую выделяют гигабайты ресурсов ради сервиса, занимающего мегабайты. В целом же, виртуализация полезный и хороший инструмент, помогающий оптимизировать расходы, если, применяя его, задаться такой целью (и такой целью тоже)
от ойтишнегов отказываемся - 100%
Верно, об этом во 2й части статьи
Про отказ от облаков давно мечтаю, собрать те же 10 сервачков на хуананже с ксеоном с помойки, упаковать в компактные корпусы - очень хорошо выйдет по стоимости/производительности, но есть нюансы….
Как минимум, если вдруг надо сервера развернуть в других странах/регионах, никак иначе не решить кроме облаков.
А своя сборка будет упираться в плохой интернет, что в МО, что в Москве - сомнительное качество провайдеров, аптайм может пострадать сильно, только колокейшн, разве что, может помочь.
Короче, как всегда, спорная тема.
это в РФ она может еще туда-сюда спортная. Тут на рынке США, уже нет никаких споров, ВСЕ в облаках. Все споры - это что выбрать AWS или Azure. Ну и тренд сейчас вообще еще дальше идет, к чистым нативным клауд решением, с уходом от контейнеров и кубернетисов.
Буду признателен за какой-нибудь ресурс про нативные Клауд решения, если такой есть
не знаю что значит ресурс, но знаю примеры решений, в дата аналитике - это клауд нативная субд Snowflake, также клауд нейтив Databriks, datalake стораджи само собой S3 или ADLS, еще есть ADF для ETL ну и понятно для репортинга - PowerBI топ1, уже тоже со своим облаком отдельным правда, но клауд решение для репортинга.
Облака нужны для быстрого создания MVP или проверки работоспособности идеи. Особенно с использованием IaC.
Использование локальных серверов теперь очень спорное решение. Т.к. создание локального подобия ЦОД очень не простая и не дешевая задача. А для территориально-распределенного бизнеса, с филиалами - откровенно опасное решение для непрерывности бизнеса.
Надежнее разместить все свое оборудование в выделенных ячейках ЦОД. Или вообще взять целые сервера в аренду. Но тут уже надо бодаться за цену и общаться с компаниями, специализирующимися на голой аренде железа. Т.к. сами ЦОД очень сильно задирают цену за аренду оборудования.
Облака нужны для быстрого создания MVP или проверки работоспособности идеи?
Мне не лень запустить виртуалку на своём лркальном сервере "для проверки идеи". (А вам?) Разработки, тестирования. А для продакшена, если сервис для внешних клиентов - тут и нужны будут облака. Чтобы 24/7 и не париться.
Возможно я не полностью раскрыл смысл MVP.
Облако будет нужно для быстрого временного разворачивания какой-либо инфраструктуры, приближенной к продуктивной, с возможностью показать достижимость требуемого результата для заказчика, или инвестора.
Под капотом легко может оказаться пара десятков VM, пара кластеров kubernetes, S3, кластер баз данных и т.д.
После демонстрации и принятия решения, все это "богатство" убивается одной командой, например в terraform/tofu.
На постоянное использование облака подходят тем, кто не может, не хочет, не готов разбираться в инфраструктуре. Это очень часто происходит, когда решения принимаются внедренцами/разработчиками программного продукта.
Автор путает бережливое производство и экономию на спичках (крохоборство).
Как всё перечисленное в статье:
Поможет увеличить предприятию выпуск продукции?
Поможет сократить складские запасы продукции?
Увеличит скорость оборота денег в бизнесе?
Ответ: Никак.
Всё, что перечислено в статье, это экономия на спичках (крохоборство) и оно не принесёт вам особой пользы для бизнеса. Также оно не имеет ничего общего с бережливым производством.
Я могу выделить человека, который 2 недели будет заниматься крохоборством согласно пунктов статьи и сэкономит моей компании некоторые ресурсы. Или же я могу поставить этого человека туда, где он принесёт больше пользы, например, в отдел продаж, где он за 2 недели сделает 4 сделки, заработанные деньги с которых будут в 3-4 раза больше, чем то, что могло быть сэкономлено на крохоборстве.
Но человек, способный адекватно разобраться с IT инфраструктурой и успешный продажник - это в принципе разные люди.
Вот из-за таких про "экономию на спичках" - многократное раздувание ИТ-бюджета и происходит! Я понимаю действительно крохоборство на мышках экономить или на считанные проценты уменьшить расход. Но я про в разы. Весь бюджет!
Туалетную бумагу ведь можно дважды использовать. У нееж две стороны!
То, что для вас "просранные деньги" для кого-то "увеличение живучести".
"Когда началось", то оказалось, что +50% запаса - отличная вещь. Пока вся страна "с попой в мыле" пыталась обеспечить себя, чтобы работало хоть как-то, те у кого был "лишний запас" спокойно на нем всё переждали.
Очень обидно терять сделки на миллионы сэкономив на тысячи.
А я увеличиваю живучесть как дополнительный профит к цели "не платить". Например: отказ от централизации, отказ от VDI - сотрудник, топ-менеджер всегда достанет нужный файл для сделки со своего компа или с серверной шары - какой бы экскаватор какое оптоволокно не перерубил. Отказ от SaaS, от миграции в западные облака - хотелось просто не платить, а в итоге нас никто не отключит по команде с Запада!
Должно быть всегда не экономия ИЛИ живучесть, а и живучесть, и экономия.
- Централизация + стандартизация уменьшают стоимость владения и стоимость обработки информации, а вы предлагаете от этого отказаться.
- Отказ от VDI. Для маленьких компаний он, действительно, не нужен, а в больших - экономит много денег, очень много денег. У нас VDI на 1 500 пользователей (центры продаж по всей стране и круглосуточный Callcenter).
- Отказ от SaaS. Не знаю, чем вам не нравится SaaS, но это самая крутая штука, которая имеется на рынке. Всякие там Мегапланы, Мой Склад, Галактика, штуки для обмена документами с контрагентами и прочее. Вы просто покупаете подписку и получаете крутые решения, которые вы никогда в on-prem получить не сможете. Всё сопровождение на стороне вендора, тонна интеграций с другими сервисами и прочее. SaaS сервисы великолепны и позволяют компании сильно упростить свою работу.
- "Стандартизация" очень изменчива, особенно в быстро меняющемся ИТ.
Ну и TCO не уменьшится от "стандартизации", если у вас проект, а не процесс.
- VDI экономит деньги, только для быстрого подключения пользователей из абстрактной существующей любой инфраструктуры в вашу информационную систему. Отчасти как и терминальный сервер. Если вы сами создаете свою инфраструктуру, то VDI, как правило, приводит к двойному перелицензированию ПО на рабочем месте пользователя и в инфраструктуре VDI.
- SaaS очень полезная идея, но она сама не становится "серебряной пулей", если заказчик постоянно не вникает во все тонкости. Живой пример "облачный" Битрикс24. После каждого обновления внутренних облачных сервисов, появляется волна бизнес-потребителей, проклинающих тот момент, когда они начали использовать этот продукт.
Например: отказ от централизации, отказ от VDI - сотрудник, топ-менеджер
всегда достанет нужный файл для сделки со своего компа или с серверной
шары
1) локальный комп сдох - файла нет.
2) чтобы была серверная шара, нужен локальный (районный, региональный) админ, который настроит эту серверную шару, соберет сервер с резервированием дисков.
Но вы же экономите, и локальная шара делается из локального писюка, простите, персонального компьютера. и см п1
Вывод, файлы не нужны. да и ваш бизнес тоже не нужен.
поддерживаю автора. могу привести примеры из сети. на предприятии стояли раньше cisco2960 на уровне аксес а им на замену вендор выпустил 9200. но покупают 9200 и 9300 вперемежку. притом что 9300 в среднем стоит 5к юсд а 9200 от 2к юсд. я спрашиваю а зачем 9300? говорят мощнее же. но зачем? юзеры как работали с файлами ворд и ексел так и продолжают работать. файлы ведь не растут в 100 раз. и даже в два раза не растут. те же самые файлы.
я помню раньше каждый пользователь был подключен к порту 100M потом стали подключать к 1G а сейчас кто то приходит и говорит каждого пользователя нужно подключать по 10G? зачем? всю кабельную проводку нужно заменить на категорию 6Е
Автор, согласен с Вами. Но есть и обратная сторона: закупка оборудования несоответствующего минимальным техническим требованиям, отказ от локальной централизации IT-структуры, минимизация расходов на сопровождении (практически невозможно доказать что обслуживание харда/софта и обеспечение ИБ - это разные задачи). Это первое, что приходит в голову, думаю можно и продолжить...
Эффективный менеджер detected.
Автор, не дай Бог кто-то Ваших советов послушает, потом переделывать вчетверо дороже встанет.
"Скорость интернета". Вы путаете передаваемые объёмы с шириной канала. Гигабайт можно передать и по гигабитному каналу, и по 10Mbps - и он даже доедет, вопрос в том, будет ли в нём смысл уже. Вы заявляете, что "объемы не так уж выросли" - Вы сами-то анализ делали? Сейчас сайт весом в мегабайты уже далеко не редкость. Кроме того, стоимость гигабитного канала 10 лет назад и сейчас - это, извините, две большие разницы.
"Собственный VPN" - Вы серьезно не понимаете, в чем разница между провайдерским VPN и поднятом на микротике openvpn? А также где заканчивается одно и начинается другое?
Зачем передавать бэкапы - геораспределённое хранение, модель 3-2-1 - не, не слышали? Я могу посочувствовать компании, воспользовавшейся Вашими советами, когда у них сгорит офис или его затопит. И да, я своими глазами видел и сгоревшие, и утонувшие СХД. В том числе и те, где не было бэкапов off-site.
Ну и так далее. Надеюсь не увидеть продолжения про ФОТ, где Вы будете доказывать, что админ за 300к не нужен и достаточно за 80. Видел несколько компаний, где после таких решений собственнику приходилось разгонять весь ИТ-отдел и строить заново почти всё, потому что это оказывалось дешевле.
Значительная часть перечисленных проблем решается изменение подхода к закупкам и выделением его в отдельное направление. Когда у вас условный сисадмин должен выбить бюджет, согласовать договор протащив его через различные службы внутри и при этом ещё и сэкономить, а потом отслеживать оптимальность потребления, то получится плохо. Возьмите отдельных людей на эту задачу. Правда жизнь показывает, что часто у этих людей липкие руки, но это уже другая проблема.
Уверяю, не решается - кроме нежелающего оптимизировать сисадмина появится ещё такой же, но менеджер. Потреблющий зарплату, не надо забывать. Чтобы оптимизировать в разы, надо хотеть знать систему на низком уровне и мыслить как хакер даже, а не просто сисадмин. Этот ваш эффективный менеджер способен и вообще захочет мыслить как хакер?
Автор не указал размер бизнеса и его профиль. Без них эту статью читать и обсуждать бессмысленно.
Если речь идёт об оптимизации затрат на ИТ в лавчонке из трёх эникейщиков - то это может иметь какой-то смысл. Но только в случае, если эти эникейщики изначально тупанули и зачем-то купили себе каналы по тарифам для крупного бизнеса.
Если мы говорим про компанию с сотнями или тысячами сотрудников, где цена отказа или потери бэкапа многократно превышает переплату за "неиспользуемые гигабайты" - то это глупо обсуждать. Бизнес скорее купит второй резервный канал за полную стоимость, чем будет экономить копейки на первом
По поводу облаков у вас тема очень плохо раскрыта. Приведу пример. На одной из моих прошлых работ проект развёрнут на AWS. Клиент платит около 2к$ в месяц за сами сервисы AWS, плюс услуги девопса ему обходятся приблизительно в 1,5к$ (это в среднем, иногда бывает больше, а иногда девопс вообще не нужен несколько месяцев). Так вот, мы посчитали, что если отказаться от AWS, оставить только файлы на S3, а само приложение развернуть в дроплете на Digital ocean (к примеру), то за такой дроплет надо будет платить около 100$ в месяц. То есть экономия в 20 раз на ровном месте. В обоих случаях это облака, только принципиально разные. Но клиент хочет AWS, чтобы всё было круто и современно. Я ребятам предлагал даже закинуть всё в дроплет и приделать фэйковую админ-панель с графиками, как будто это микросервисы и продать это клиенту например за тысячу баксов в месяц :D
Именно так лет 70 назад в архитектуре отказались от "излишеств" и настроили "хрущёвок".
А если серьезно, то надо от бизнес-задач и бизнес-модели исходить. Многие бизнесы предпочтут облака из-за time to market, и надёжного аптайма.
Чем раньше эффективных менеджеров - демагогов показательно вышвыривают из компании, тем меньше негативных последствий их деятельности компания испытывает
Экономия на презервативах:
Hidden text
У мужика есть 2 презерватива и 3 клевые подруги, но все с разными венерическими заболеваниями. Спрашивается как ему трахнуть этих подруг, так чтобы ни одна зараза не перешла к нему, но и ни одна из подруг не получила новой заразы
Пойду в бухгалтерии мониторы 27"/1440p заменю на 22"/1080p, а то че это они деньги тратят )
Статья коротко:
Если вы переплачиваете - вы можете не переплачивать!
С одной стороны всё так.
С другой:
1) статья по осмысленности как подробно написать, что многие предметы роскоши, бренды и фешн вещи не нужны.
2) не имеет смысла без оценки рисков и затрат на оптимизацию. Это один умный коллега сказал, ято есть два подхода QoS (условно кроим имеющеся) и over-Engineering: закладываем трубу такой ширины, что не надо этим заниматься и проблем быть не должно.
3) Глобально (в рамках рынка, а не отдельно взятой конторы) всё это (over-потребление) двигает технологии, делает их дешевле и доступнее, что есть хорошо.
Но вторую часть с интересом почитаю.
Публикации
Многократные переплаты в ИТ и где они возникают. Ч.1