Сокращение найма в ИТ

[Mad Hatter]

Это продукт которым пользуется компания, в данном случае Domino Pizza.

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

Спланк дорогой, я в курсе
Кстати основная часть вашего била это не Data ingestion, а стоимость queries
Плохо сконструированные dashboards могут жрать много денех.

[Женя Стоунер]

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

Спланк дорогой, я в курсе
Кстати основная часть вашего била это не Data ingestion, а стоимость queries
Плохо сконструированные dashboards могут жрать много денех.

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

[Mad Hatter]

Если хочется Splunk, то грамотно настроенный onprem экономит кучу денег на кверис. Другое дело если у вас данных слишком много и onprem их сожрать уже не может, то только клауд со своим ценником. Там уже сам Splunk какую-то черную магию с load balancing творит.

[kolbasof]

У вас неверное умозаключение. Обьем обрабатываемых данных растёт быстрее чем процессорная мощность.

Смотря кем обрабатывается. Большинство компаний как работало с базовыми данными кастомеров в 90х, так и работает дальше, здесь г-н Колбасов прав. Сильно вырос объем метаданных, observability, usage tracking, BI, теперь появились RAG с векторами. Здесь правы вы. Но это обычно уходит в облака специализированных компаний, которые затем возвращают обобщенные аспекты той компании, которая изначально собрала данные.

Да, количество транзакционных данных, где важны аккуратность и производительность кода, не сильно выросло, а вот поток всякого неструктурированного барахла вырос стократно. В обработке потока барахла точность и надежность программ не важна, поэтому и низкие требования к качеству кода. В случае OLTP компенсируют набиванием системы железом, а не вылизыванием кода. Помнится что в 90х пиратский дистрибутив MS Word влезал на 6 дискет 3.5", т.е. около 15Мб, а сейчас 2Гб. При этом используется на 90% как простая пишущая машинка.

[Женя Стоунер]

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

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

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

[Женя Стоунер]

Помнится что в 90х пиратский дистрибутив MS Word влезал на 6 дискет 3.5", т.е. около 15Мб, а сейчас 2Гб. При этом используется на 90% как простая пишущая машинка.

Это вы отдельный вопрос подняли. MS производит bloatware/говно, потому что это их основное свойство, OS, IDE, язык программирования C#, орг.структура - все bloatware/говно. Ожидать что ПО будет другим сложно.

[voyager3]

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