Администрирование

Всем привет! Возникла задача - штатными средствами Windows (то есть через PowerShell) отслеживать дату оставшейся валидности сертификата безопасности (TLS\КСКПЭП) и выводить уведомление, если дата подходит к концу (мы сделаем ботом в telegram чтобы быть в курсе, даже находясь на больничном или в отъезде). Мы не используем сторонние языки программирования, сторонние сервисы для отслеживания (хоть платные, хоть бесплатные), не полагаемся на уведомления от удостоверяющих центров на почту, а попробуем сами поупражняться с PowerShell. Нам не нужно будет разворачивать под это отдельный сервер, грузить куда-то кучу своих сертификатов, изучать Python. Только штатный PowerShell, только хардкор.

Эволюционируя из рядового сисадмина в DevOps-а, специалисты начинают заботиться о разработке. В среднем разработчики об инфраструктуре знают не очень много: вполне может добавить скрипт, который обрушит кластер. Поэтому наша задача как девопсов сделать систему максимально отказоустойчивой, автоматизировать рутину, выстроить процессы CI/CD, настроить мониторинг и вообще следовать подходу “Инфраструктура как код”.

Но это в теории. На практике это возможно, только если в систему никто не вносит никаких изменений, а так не бывает. Поэтому жизнь DevOps - постоянный “День Радио” в отдельно взятой инфраструктуре.

Врезка: “День Радио” — это фильм с сюжетом, что в прямом эфире вот-вот должен стартовать марафон, но за десять минут до начала выясняется, что заранее подготовленная тема перехвачена конкурентами. И начинается суета и множество сюжетных поворотов и проблем 🙂

Я поговорил с Дмитрием, тимлидом DevOps-команды в Git In Sky. Обсудили, как выглядит его типичный рабочий день и какие задачи стоят перед командой в условиях активно растущего рынка SRE-аутсорсинга.

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

Всем привет, меня зовут Аббакумов Валерий.

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

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

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

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

CPU (центральный процессор) — это сердце любой вычислительной системы. Эффективное использование CPU напрямую влияет на производительность приложений и всей системы. Даже если Ваш сервер решает задачи абсолютно не требовательные к вычислениям (хранит архив файлов, к которым раз в месяц кому-то нужен доступ), он все равно не может делать это без использования CPU.

В этой серии статей Кирилл Казарин, Senior DevOps и SRE менеджер, автор телеграм-канала Kazarin.online и спикер курса «Администрирование Linux», рассмотрит ряд аспектов, связанных с CPU в Linux и влияющих на производительность ваших приложений и сервисов с точки зрения CPU, включая такие понятия, как утилизация процессора, load average, многопоточность, NUMA, а также различия между архитектурами x86 и ARM. Цель этой статьи — дать общее представление об использовании ресурсов CPU в Linux.

Привет! Меня зовут Виталий Флёрин, я руководитель отдела BI-аналитики в M2. За год мы успешно перевели всю отчетность компании с Cognos Analytics на Apache Superset и увеличили MAU до 200 (каждый третий сотрудник компании). В статье хочу поделиться опытом внедрения новой системы отчетности и ее эффективного использования.

Материал будет полезен BI-специалистам, кто работает над развитием внутренних систем и хочет переехать на Superset.

История началась с того, что после ухода Cognos Analytics с российского рынка, нам нужно было выбрать новую BI для компании и мигрировать всю отчетность. Текущая система была развернута on-premises и продолжала работать в штатном режиме. Да, без обновлений и поддержки, но благодаря этому мы смогли тщательно подойти к выбору нового решения и обеспечить плавный переход пользователей на новую платформу.

Установка Arenadata DB 7.2 выполняется с помощью Arenadata Cluster Manager (ADCM). Это средство предназначено для разворачивания кластера на большом числе хостов с большим объемом оперативной памяти на каждом из них. А если кластер Arenadata нужен не для производительной работы, а для проведения экспериментов или для разработки/тестирования, можно ли развернуть его на компьютере с небольшим объемом оперативной памяти, например, 32 Гб? Будет ли кластер работать стабильно? Позволит ли он выполнять тяжелые операции? Каково минимальное количество виртуальных машин, на которых можно запустить Arenadata DB 7.2?

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

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

Главная идея — чтобы поиск был удобным и позволял максимально быстро сузить воронку результатов, то есть вычленить из миллионов дел именно те, которые подходят под заданные параметры.

В этой статье мы поговорим о важном аспекте тестирования, с которым столкнулись в работе над одним из наших продуктов — шлюзом веб-безопасности Solar WebProxy (Secure Web Gateway, SWG). Эта система защиты, которую еще называют веб-прокси, контролирует передачу данных между сотрудниками, внутренними ресурсами организации-клиента и интернет-ресурсами.

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

Чтобы решить эту проблему при создании Solar webProxy, мы разработали собственный калькулятор производительности, который дает нам и заказчику реальное представление о ресурсах, необходимых для эффективной работы нашего веб-прокси.

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

Рано или поздно в современных российских реалиях нужно уходить от связки MS + RADIUS + Cisco. В нашем случае необходимо было реализовать подобный функционал через импортозамещающие варианты.

MGCom — одно из ведущих российских агентств в сфере performance‑маркетинга, специализирующееся на контекстной и медийной рекламе, аналитике, медиапланировании, проведении маркетинговых кампаний, SMM и SEO.

К началу 2025 года штат компании вырос до 1800 сотрудников. Разместить такое количество сотрудников в 5-этажном офисе на Цветном бульваре удалось только благодаря организации гибридного формата работы.

Данные — это новая нефть. От эффективности работы с ними напрямую зависит успех любого проекта, особенно в эпоху микросервисов. В этой статье мы погрузимся в мир данных и рассмотрим его с точки зрения Java-разработчика, который хочет добиться продуктивности и оставаться во всеоружии при работе с любыми объемами информации.

Цель этой статьи - предоставить полное руководство по структурам, концептам и инструментам для работы с данными в экосистеме Java, с уклоном в микросервисную архитектуру.

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

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

Приветствую, коллеги! Меня зовут @ProstoKirReal. Мне бы хотелось с вами обсудить как работает интернет от кабелей на витой паре, соединяющие простые локальные сети до подводных коммуникационных кабелей соединяющие между собой континенты и основные операторские сети.

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

В этом цикле статей я не стану учить вас настраивать оборудование и проектировать сети. Я расскажу об основных (и не только) принципах построения сети, а также о функционировании сети и сетевых протоколов в стеке TCP/IP.

Привет всем! Перед деплоем нового релиза приложения в продакшен хорошей практикой является оценка его работы с запросами от реальных пользователей. Если разом заменить текущий релиз приложения на новый, есть вероятность в случае ошибки в программном обеспечении повредить данные большого числа пользователей или получить непрогнозируемое поведение нового релиза под нагрузкой. Чтобы избежать указанных трудностей используют Canary‑релизы — это когда рядом с актуальным релизом приложения в продакшене развертывают релиз с новой версией приложения и направляют на него часть запросов от реальных пользователей. В данной статье мы расскажем о нашем опыте внедрения Canary‑релизов в CI/CD платформу Gitorion.

Как же иногда хочется закинуть коммиты «Remove debug log», «fix» или «fix fix fix». Такие коммиты как грязные носки под кроватью: их не видно, пока не придёт ревьюер с пристальным взглядом или, что еще хуже, потенциальный работодатель, решивший посмотреть на ваш профиль github.

К счастью, Git предлагает два супер-инструмента для того, чтобы история коммитов выглядела так, будто ты всегда знаешь, что делаешь: git commit --fixup и git rebase --autosquash. И сегодня мы разберем на практике как это применять.

Используете готовые операторы в Kubernetes? Я тоже... Но с какого‑то момента я начал задаваться вопросом: «а как люди их пишут?». И я нашел ответ!

В этой статье я наглядно покажу, как создать свой кастомный оператор в Kubernetes на Go при помощи kubebuilder. Оператор позволит отслеживать изменения ресурсов в кластере, а затем отправлять уведомления в Telegram или другие мессенджеры. Какие ресурсы «трекать» будем описывать через кастомные ресурсы (Custom Resource). Погнали!