О скрипте: быстрая и безопасная оценка экспозиции устройств Cisco IOS/IOS XE, связанная с CVE-2025-20352 (подсистема SNMP).
Сканируем подсети на SNMP через onesixtyone с дефолтными сообществами. Парсим баннеры sysDescr.0 Python-скриптом: помечаем Cisco IOS/IOS XE и проставляем статус Fixed (если в белом списке) или Potentially Vulnerable (проверить в Cisco Software Checker).
Проект не эксплуатирует уязвимость. Он лишь определяет устройства, отвечающие на дефолтные SNMP-сообщества, и извлекает версию из sysDescr.0.
Подборка обучающих материалов по Docker и Kubernetes
Привет, Хабр! Сегодня пятница, поэтому я снова со своей нерегулярной подборкой полезных материалов для начинающих специалистов. На этот раз несу статьи о Docker и Kubernetes. Как обычно: все бесплатно, без регистрации и смс. Читайте и практикуйте.
Первые шаги в Kubernetes
Здесь 12 статей примерно на два часа чтения. Будет полезно, если нужно освоить базу: что такое K8s, какие задачи помогает решить, основные понятия, с чего начать, как работать с контейнерами и настроить мониторинг.
Docker с нуля: как работают контейнеры и зачем они нужны
Эта подборка из шести статей — ваш гид в мир контейнеризации. Вы узнаете, что такое Docker, как запускать контейнеры, собирать образы и использовать Docker Compose, а еще разберетесь, чем эта технология отличается от Kubernetes. Все материалы подкреплены практическими примерами и будут понятны начинающим. На полное изучение уйдет менее двух часов.
Основы безопасности в Docker-контейнерах
Если вы прочитали предыдущую подборку и почувствовали в себе силы начать работу с контейнерами, не спешите. Изоляция, которую они обеспечивают, может вызывать ложное чувство безопасности. Чтобы вы могли погрузиться в вопросы защиты своего Docker, есть еще одна мини-подборка из трех исчерпывающих материалов. Изучение — чуть больше часа, а эффект — бесценен.
Приглашаем на Infra Meetup от Wildberries & Russ! Расскажем про внутреннее файловое хранилище собственной разработки, поговорим о методах автоматизации репозиториев в Nexus, разберём существующие сервисы и процедуры их сопровождения, обеспечивающие бесперебойную работу. И обязательно затронем важнейшую тему культуры инженерного взаимодействия в команде.
В программе:
Файловое хранилище Wildberries: бескомпромиссный HighLoad | Иван Волков, CTO CDN
Как устроено одно из важнейших файловых хранилищ Wildberries
1,2+ млн RPS на выдачу фото и видео — и это не предел
Код Оккама: органический подход к разработке и процессам
Путь автоматизации репозиториев в Nexus | Владислав Раев, DevOps & DevTools Engineer
Автоматизация без стандартизации, или путь в никуда
Что работает для 10, может сломаться на 100
Меньше состояния — меньше проблем
Явное лучше неявного
У вас завелся сервис: рекомендации лучших сервисоводов (наверное) | Александр Стовбунский, Tools Team TechLead
«Пап, можно мы его оставим?» — почему приносят одни, а чиним мы
«А выгуливать кто будет?» — что может требовать тот, у кого нет права отказаться
«Он большим не вырастет!» — как считать трудозатраты и сроки
Вредные советы: как гарантировано всё испортить
Для участия в офлайне она обязательна. После докладов — продуктивный нетворкинг и афтерпати.
Мы создали графический установщик, который превращает развёртывание Deckhouse Kubernetes Platform в несколько кликов и упрощает начало использования платформы через веб-интерфейс.
На вебинаре 25 сентября технический директор веб-интерфейсов Deckhouse покажет live-демо Installer:
Развернёт полноценный кластер Deckhouse Kubernetes Platform за 10 минут.
Включит виртуализацию ещё за 10 — и запустит Doom на виртуальной машине.
Расскажет, какие проблемы установки закрывает Installer.
Покажет планы развития графического установщика и где его взять.
Привет всем хабровцам! Мы регулярно публикуем посты о наших вакансиях, включая 1С и DevOps.
Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на портале хх необязательно — внизу дадим прямые контакты с нашим HR.
Рабочие места в офисах в Москве (топ локация в ЦАО у Красной площади) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Вот примеры вакансий 1С и девопс — остальные 20 штук на см. на хх.ру:
Из сегодняшнего. Давно уже напрашивается MCP registry. Появился MCP реджистри. Не знаю, насколько аудитория погружена, поэтому если нет, то я подробнее распишу
Model Context Protocol (MCP) — это не классическое API, а новый слой взаимодействия между LLM и источниками данных: вместо того чтобы самому писать запросы, интеграции и «велосипеды», бизнес просто подключает MCP-серверы, которые находятся у провайдеров данных. Провайдер отвечает за подготовку промптов, функций, агрегацию источников и поддержку версий, а компания получает централизованный доступ к данным и готовым описаниям. Важно: MCP разводит зоны ответственности — финансы за работу LLM остаются у вас, а ответственность за качество данных и промптов несёт провайдер; таким образом, вы оптимизируете бюджеты, снижаете риски и можете гибко строить оркестрацию (через LangChain или свои пайплайны) без затрат на «ручные» интеграции с контролем версий отпровайдера
Раньше каждая команда или компания искала MCP-сервера вручную, через частные списки или разрозненные каталоги, что замедляло внедрение и поддержку клиентов. Теперь MCP Registry выступает единым «источником правды», где можно быстро находить, подключать и проверять сервера
Думаю, что ближайший год-два мы будем наблюдать, как наровне с публичными АПИ, будут появляться публичные MCP для интеграций. Что уж там, они есть уже у 1С даже, хотя там нюансы, конечно
LLamaSwap - гибкая альтернатива Ollama Ollama — прекрасное приложение, основанное на llama.cpp, которым я пользовался для инференса локальных моделей до недавних пор, однако у него есть несколько критических недостатков:
Отсутствие поддержки всех GPU и BLAS, доступных в llama.cpp. Для меня это стало проблемой после перехода на Radeon RX 6800: инференс через Vulkan на llama.cpp работает быстрее и стабильнее, чем ROCm, но Ollama не поддерживает Vulkan.
Отсутствие тонкой настройки. Например, на момент написания статьи в Ollama нельзя выгружать часть MoE-слоев на CPU, что позволяет сильно увеличить скорость инференса при нехватке VRAM для загрузки всех слоев на GPU.
Ollama использует собственное хранилище моделей, несмотря на то, что под капотом работает с GGUF. Если загрузить модель с Hugging Face, Ollama всё равно скопирует её в своё хранилище, а модели в наше время весят не мало и занимают лишнее место на SSD.
Функции доступные в llama.cpp появляются в ollama с задержкой , а иногда и вовсе не появляются.
Мне нужна была альтернатива, способная динамически управлять загрузкой моделей в памяти через API без моего участия, как это делает Ollama, но без вышеперечисленных недостатков. В итоге я остановил выбор на проекте llama-swap.
Llama-Swap — приложение на Go, которое запускает несколько инстансов llama-server и проксирует запросы к ним по заданным правилам.
Плюсы по сравнению с Ollama:
Полный доступ ко всем возможностям llama-server (например --override-tensor для выгрузки MoE слоев на CPU).
Поддержка большего количества GPU кскорений (таких как Vulkan или даже связки Vulkan + CUDA)
Возможность настроить отдельную версию llama-server для каждой модели (если в будущих обновлениях что то сломается).
Более гибкая настройка правил загрузки/выгрузки моделей в память: (одновременная загрузка, поочередная по запросам).
Не дублирует модели на диске (если используются форматы поддерживаемые llama.cpp).
Из коробки есть WebUI для управления загрузкой/выгрузкой моделей.
Минусы:
Из коробки не работает, требуется настройка через config.yaml и наличие рабочего llama-server.
Проект молодой, и его дальнейшая судьба пока не ясна.
Основные пункты файла конфигурации
Список моделей с указанием их расположения и параметров запуска (влючая путь к llama-server).
Группировка моделей, к группам применяются правила загруpки/выгрузки из памяти: - Все модели в группе загружены одновременно. - Модели загружаются по мере поступления запросов
Различные настройки прокси, порты, таймауты и пр.
У меня мини-ПК с интегрированной Radeon 780m, 32 ГБ ОЗУ и eGPU RX 6800. Я полностью перешел на Llama-Swap + OpenWebUI и всё больше отказываюсь от использования онлайн-сервисов вроде OpenRouter — ведь возможностей моего недорогого, по современным меркам ПК, хватает для запуска, таких моделей как Gemma3 30B и Qwen3-Coder-30B-A3B-Instruct. Думаю, в скором времени, когда ПК с объёмами памяти от 64 ГБ и выше станут ещё дешевле, интегрированная графика — мощнее и на рынке окажется множетсво БУ GPU с объемом VRAM 16ГБ и выше, часть людей, использующих LLM для своих задач, сможет полностью перейти на локальный инференс. Хотя это, возможно, это только моя фантазия. Всем спасибо за прочтение.
Успеть за пять дней: отклик — интервью — оффер за пять дней для инженеров по безопасности
Надежные продукты начинаются с безопасного кода. Команда безопасности следит за уязвимостями, укрепляет процессы и поддерживает CI/CD в форме. И мы в YADRO укрепляем команду — ищем специалистов на позиции Application Security Engineer и DevSecOps. Принимаем заявки до 28 сентября.
Это вакансия на позицию инженера по безопасности приложений, который поможет создавать устойчивые к атакам продукты и внедрять лучшие практики SSDLC на всех этапах разработки. В этой роли вы будете:
проводить триаж уязвимостей, найденных с помощью SAST, SCA, Secret Detection и других инструментов;
оценивать защищенность продуктов на основе моделей угроз и выполнять специализированные тесты (fuzzing, сканирование портов и др.);
исследовать новые векторы атак и участвовать в тестировании на проникновение;
разрабатывать PoC решений для функций безопасности;
участвовать в выборе и внедрении инструментов тестирования.
Подать заявку и узнать больше о вакансии можно по ссылке →
DevSecOps / Infrastructure Engineer
Присоединяйтесь к нам в роли инженера, который будет развивать практики DevSecOps, совершенствовать подходы к безопасности инфраструктуры разработки и CI/CD, а также помогать командам интегрировать проверки безопасности в процессы. В этой роли вы будете:
внедрять и развивать DevSecOps-практики;
выявлять и устранять угрозы в инфраструктуре продуктов и CI/CD-процессах,
проектировать и внедрять безопасную архитектуру CI/CD;
обеспечивать стабильную работу инструментов SAST/SCA/DAST и создавать Quality Gates;
автоматизировать процессы с помощью GitLab CI, Ansible, Helm;
ставить задачи командам по улучшению безопасности и контролировать их выполнение.
Изучение Python может показаться сложным, но с правильным подходом и пониманием ключевых аспектов процесс станет понятным и увлекательным. Привет, я Иван Чернов, senior system architect, кратко расскажу, как начать вкатываться в Python, с какими проблемами сталкиваются новички и как их преодолеть.
Первые шаги
Определяемся с направлением, в котором вы хотите развиваться. Это может быть веб-разработка, машинное обучение, DevOps и т. д. Каждое направление требует своих знаний и навыков. Поэтому важно понять, что конкретно вам интересно и на какой позиции не будет скучно или слишком сложно.
Начните с изучения базовых понятий, таких как переменные, типы данных, структуры данных и функции. Это заложит фундамент для дальнейшего изучения.
Когда определились с направлением и изучили теорию — проходите курсы с практическим обучением или начинайте работать с кодом сами. Всегда лучше писать, чем читать. Как только вывели “Hello, World!”, переходите к обучающим программам, где первые задачки применимы к жизни. Например, на некоторых курсах учат разрабатывать Telegram-бота под ваши нужды. Это отличная практика для понимания процессов.
Также можете прочитать базу «Питона» — книгу “Automated Boring Stuff with Python”. В ней много практических задач, которые помогут вам освоить язык. А ещё есть полезный курс “Learning How to Learn”, который учит, как правильно учиться, опираясь на достижения нейронауки.
Этап, на котором новички отваливаются
При более глубоком изучении «Питона» новичок столкнётся с первой проблемой — настройкой инфраструктуры. На этом этапе многое пугает: установка редакторов кода, интерпретаторов, пакетных менеджеров и прочее. Даже опытные программисты каждый день ищут подходящие инструменты и пытаются освоить новые.
Чтобы облегчить старт, можно для начала научиться использовать онлайн-среду разработки, например Replit. Можно просто зайти на сайт, выбрать язык Python и сразу приступать к написанию кода.
Replit — это сервис для вайб-кодинга. В нём можно быстро экспериментировать с задачами и сразу видеть результат. Так вы сконцентрируетесь именно на изучении языка, а не на технических сложностях.
Тут есть большое «но»: на вайб-кодинге далеко не уедешь. Использование онлайн-сред — это чит-код, который облегчает старт, но не учит решать реальные проблемы. Так что с комплексной инфраструктурой всё же придётся разобраться.
Концептуальные вопросы
Отдельно стоит отметить концептуальные вопросы, которые могут возникнуть на старте. Новички часто сталкиваются с трудностями в понимании таких понятий, как переменные и функции.
Например, в Python переменная может принимать разные значения, что противоречит математическим представлениям. Это может привести к путанице и неправильному пониманию основ программирования.
Важно понимать, что программирование — это не только про то, как писать код, но и о то, как мыслит как программист. Необходимо развивать критическое мышление и осознавать, что многие концепции, которые мы учили на уроках математики, могут быть неверными в программировании.
Советы начинающим питонщикам
Постоянная практика. Пишите код каждый день, хотя бы немного. Работайте над проектами, которые вас интересуют, и решайте проблемы, которые вас раздражают. Я в 2010-м хотел, чтобы дома лампочка включалась по голосу. С помощью Python удалось сделать это.
Изучайте чужой код. Чтение и понимание чужого кода поможет вам увидеть, как другие решают задачи и какие подходы используют. Однако не стоит изучать рандомный код. Лучше ищите тот, что поможет улучшить ваши проекты.
Go sport, go team. Физическая активность способствует лучшему усвоению информации. Поэтому не забывайте делать перерывы и заниматься спортом.
Заключение
Определитесь с направлением, изучите теорию, но не медлите с практикой. Не пугайтесь сложностей инфраструктуры: всегда можно нагуглить или спросить на форумах. Пользуйтесь онлайн-средами, но не делайте большую ставку на вайб-кодинг. Не бойтесь начинать и ошибаться — и у вас всё получится.
Наступает осень, а значит и высокий сезон в IT. У нас больше 20 вакансий в командах аналитиков, девопсов, QA и разработчиков. Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224. Но откликаться на хх необязательно — внизу дадим прямые контакты с нашим HR.
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (топ локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
Резюме на вакансии 1С, Elixir, Ruby, девопс и инфобез — рассмотрим в приоритетном порядке.
Data Scientist
DevOps-инженер
Data Scientist
DevOps-инженер
Сетевой инженер
Тестировщик 1C
QA Auto Java
Automation QA Engineer (Lead)
Elixir разработчик
Middle Java Developer
Ruby Developer
Jira Developer
С++ Developer (Senior)
Ведущий разработчик 1С (ERP, УХ)
Разработчик 1С (ЗУП)
Разработчик DWH
Аналитик DWH
Ведущий аналитик 1С ERP
Аналитик 1С (Управление недвижимостью и арендой)
Аналитик 1С (регламентированный учет)
Мы ценим сотрудников — работа без лишней бюрократии — акцент на задачи, которые приносят результат и развитие профессиональных навыков. 🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм с прицелом на долгосрочную совместную работу. Многие сотрудники у нас работают по 5 лет и более.
Data Sapience приглашает на онлайн-конференцию «Kolmogorov Online Day» ⚙️
Эксперты Data Sapience раскроют секреты эффективного управления жизненным циклом моделей и расскажут, как увеличить отдачу от ML-инвестиций.
Дата: 18 сентября 📆 Время: 16:00 ⏰ Формат: онлайн 🌐
Что будет представлено: ▪️Достижения Kolmogorov AI: этапы развития, ключевые результаты; ▪️«Тессеракт» — обзор нового ПАКа для создания доверенных моделей ИИ; ▪️Срез практик MLOps — объективный взгляд на тренды и подводные камни, а также подходы к работе с AI от независимых экспертов; ▪️Демонстрация возможностей Kolmogorov AI для построения фабрики ИИ-агентов.
Вебинар будет полезен тем, кто хочет: ▪️Автоматизировать и ускорить вывод моделей в production; ▪️Наладить эффективный MLOps и перейти от экспериментов к промышленной эксплуатации; ▪️Найти подходящие инструменты и узнать об опыте создания надежной, масштабируемой и высокопроизводительной инфраструктуры для ML-моделей.
Сегодня, 9 сентября, в мире ИТ вспоминают первый компьютерный баг
В 1947 инженеры Гарвардского Mark II под руководством Грейс Хоппер разбирались с поломкой реле. В какой-то момент они нашли причину — внутри застряла настоящая моль. Её аккуратно извлекли, приклеили в журнал отладки и подписали: «Первый реальный случай бага».
До этого слово “bug” использовали в инженерной среде, но именно этот случай сделал его легендой ИТ.
Забавно, что сама моль сохранилась — её до сих пор можно увидеть в Смитсоновском институте.
С тех пор баги перестали быть буквальными насекомыми, но последствия стали куда серьёзнее.
Вспомнить хотя бы Heartbleed — уязвимость в OpenSSL, обнаруженную в 2014-м. Одна ошибка в библиотеке, которая отвечает за шифрование, открыла доступ к памяти миллионов серверов по всему миру. Пароли, ключи, данные — всё оказалось под угрозой. В СМИ её называли «самым громким багом десятилетия».
Через несколько лет весь мир обсуждал уже Log4j. Казалось бы, скромная библиотека для логирования на Java, использующаяся в тысячах приложений. В декабре 2021 обнаружили, что через неё можно удалённо выполнить произвольный код. За считаные часы уязвимость стала глобальной катастрофой: под угрозой оказались банки, облачные сервисы и даже игровые платформы вроде Minecraft.
В обоих случаях баг оказался не меньше, чем та самая моль в реле. Только если в 1947-м инженер мог достать насекомое пинцетом и продолжить работу, то сегодня одна ошибка в коде способна обрушить бизнес-систему мирового масштаба.
И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.
Kubernetes — стандарт де-факто для оркестрации контейнеров. Но вместе с популярностью растут и риски. Ошибка в настройке кластера может стоить компании гораздо дороже, чем баг в коде. Как избежать подобных ошибок будем разбираться на бесплатном вебинаре «Проблемы безопасности в инфраструктуре Kubernetes».
📅 Дата: 26 августа 2025
⏰ Время: 16:00–17:00 (Мск)
В программе:
✔️ Культура DevSecOps и её связь с Kubernetes
✔️ Разбор реальных проблем безопасности
✔️ Поиск уязвимостей в инфраструктуре
✔️ Живая демонстрация
Вебинар будет интересен для разработчиков, тестировщиков, сисадминов и DevOps-инженеров.
💡 Если Kubernetes — часть вашей работы, этот эфир поможет избежать критических ошибок.
Компания PVS-Studio и платформа Securitm заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Облачный сервис и программное обеспечение SGRC Securitm позволяют построить управление информационной безопасностью на базе риск-ориентированного подхода и единой информационной модели компании.
Отчёт анализатора PVS-Studio стало возможным загрузить в Securitm для дальнейшего использования с помощью пользовательского интерфейса системы.
Подробнее о том, как загрузить отчёт анализатора PVS-Studio в систему Securitm можно прочитать в посвящённом этому разделе нашей документации.
Также мы с коллегами из Securitm провели совместный вебинар, на котором обсудили, как обеспечить соблюдение требований ГОСТ в области РБПО, а также показали реальные примеры использования PVS-Studio и Securitm.
DORA - это DevOps фреймворк из 4-х метрик, которые помогают оценить эффективность и качество релизного процесса.
Фреймворк придумала компания с таким же названием (DevOps Research and Assessment). Скорее всего, чтобы проще продавать свой консалтинг. В 2018-м году эту компанию купил Google Cloud и сделал своей... командой.
Вообще, про эти метрики в том или ином виде я знал. Но не знал, как они систематизированы и по-умному называются.
Собственно, сами метрики:
1) Частота деплоя (deployment frequency)
Показывает, насколько адекватный уровень автоматизированного тестирования. И умеет ли команда релизить точечно, а не сразу всё.
Критерии:
отлично: несколько раз в день;
хорошо: раз в 1-7 дней;
средне: несколько раз в месяц;
плохо: реже, чем раз в месяц.
2) Время от коммита до деплоя (Lead Time)
Показывает, как долго мы тормозим с бюрократией после момента, когда код уже готов. Низкое значение - неэффективное тестирование, процессы ревью или разработки.
Критерии:
отлично: меньше дня;
хорошо: от 1-го до 7 дней;
средне: 7-30 дней (*по оценке компании DORA, я бы сказал, что это плохой результат);
плохо: дольше месяца.
3) % сбоев после релиза (Change Failure Rate)
Показывает, как часто мы ломаем прод релизами. Что говорит о том, насколько хорошо мы прорабатываем требования, умеем тестировать и в целом о предсказуемости того, что мы выкладываем.
Критерии (% релизов, которые привели к сбою):
отлично: <5%;
хорошо: <10%;
средне: <15%;
плохо: >15%.
4) Скорость восстановления (Mean Time To Recovery)
Показывает, как быстро мы поднимаем прод, если он сломался (упал, пришёл DDOS, выключились сервера). А ещё, умеем ли мы определять и измерять сбои. Упавшим продомом считается или факт того, что существенная часть системы недоступна, или коммит с hotfix'ом.
Критерии (как быстро поднимаем прод):
отлично: меньше часа;
хорошо: меньше дня;
средне: меньше дня;
плохо: больше дня.
Когда это нужно?
Для себя я выделил три критерия, когда эти метрики имеет смысл считать:
Когда есть конкретный продукт в активной стадии развития с постоянной командой хотя бы из 3-5 разработчиков. Т.е. это не что-то, что получает несколько фич в месяц или находится в стадии активного саппорта.
Когда компания большая, в которой появилось много команд с продуктами и нужно выстроить хоть какое-то понимание в среднем по компании. Вот тут, кстати, важно не начать погоню за метриками, т.к. все внутренние проекты живут в своём темпе. Нельзя выставить одинаковые метрики всем поголовно в качестве KPI.
Когда СТО\CIO нужны хоть какие-то метрики для отчётности. Чтобы объяснить инвесторам или нетехнической части C level'a, что в компании или команде хороший DevOps процесс (или, наоборот, плохой).
DORA метрики измеряются через GitLab или почти любую другую систему CI \ CD. GitLab умеет считать всё это из коробки. За исключением, наверное, падения прода (что тоже можно добавить вручную или вебхуками \ alert manager'ами).
---
Мой Telegram канал про разработку. Мой open source проект для бекапа PostgreSQL - GitHub.
Docker долго был самым популярным инструментом контейнеризации, но сейчас все больше сервисов переходит на Podman. Вы уже умеете работать с ним? Тогда проверьте свои знания базовых команд.
Практически каждый день я читаю и узнаю что-то новое про разработку. Решил начать вести посты в формате "Я узнал о... (какой-то факт)"
В краткой форме буду рассказывать о чем-то, что узнал за последнее время
---
Я узнал о... #1: FinOps
Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).
Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее
Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.
Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.
McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.
Например:
сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);
сервера для тестировщиков и стейджинга, которые мы купили и забыли про них;
прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).
Контроль делается за счёт того, что:
Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;
Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;
Каждый инстанс закрепляем за конкретной командой или человеком, чтобы посчитать ROI этой команды в контексте инфраструктуры.
Дополнительный бонус: CTO проще объяснить фин. директору, куда и зачем мы платим, и сколько примерно денег потребуется на следующий период.
Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.
Даже есть подходы, когда инстанс нельзя использовать, пока не добавишь его в директорию всех инстансов компании. Но как это всё использовать - пока не вникал. Просто теперь знаю, что такие опции есть
Когда это нужно?
Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".
Когда расходы >$30к/мес. и оперативной памяти ответственного лица не хватает - можно начинать думать об автоматизации сбора метрик. Иначе до этого момента автоматическое сведение метрик воедино рискует просто не окупиться
---
Мой Telegram канал про разработку. Мой open source проект для бекапа PostgreSQL - GitHub.
