IT-инфраструктура *

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

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

Привет, Хабр! Меня зовут Кирилл, я работаю в IT более 13 лет. Сначала инженером по внедрению, потом DevOps, потом SRE, также работал руководителем группы сопровождения. Сейчас SRE в VK Рекламе, поэтому знаю, как важно делать правильные инструменты для анализа проблем. 

В любом проекте и компании я иногда сталкивался, а иногда сам создавал проблему: огромное количество дашбордов. Вспомните ситуацию, когда вы в Grafana ищете какой-нибудь дашборд, пишете, например, «Tarantool», и вам выпадает огромный список дашбордов, которые кто-то до вас насоздавал. Это могут быть кастомные дашборды, которые кто-то делал для какого-нибудь инцидента, или просто созданные другими специалистами. Часто бывает, что половина этих дашбордов нерабочие или на них нет чего-то полезного. 

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

Задумывались ли вы о том, как изменить конфигурацию сразу на нескольких сетевых устройствах? Что, если нужно сделать это на всей сети с сотнями и тысячами единиц оборудования? А что, если приходится делать это каждый месяц на железе от пяти разных производителей? Очевидное решение для подобных задач — автоматизация. Но реализовать её можно не одним способом, а в процессе наткнуться не на одни грабли.

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

В этой статье проведём небольшую экскурсию по нашему сетевому «хозяйству» в десятки тысяч устройств и остановимся подробнее на том, как при таком объёме мы автоматически обновляем конфигурации.

В своем последнем отчете AFCOM (Association For Computer Operations Management) отмечают, что стремительное развитие искусственного интеллекта и широкое распространение цифровых сервисов стимулируют спрос на инновационные технологии в области проектирования ЦОД. Однако в ходе проведения исследования в AFCOM пришли к выводу, что хотя индустрия дата-центров и переживает «бум в области проектирования и строительства инфраструктуры», вместе с тем возникают и новые проблемы в таких ключевых аспектах, как энергопотребление, охлаждение и реализация целей устойчивого развития.

Команда редакции Хабра КРОК подготовила для вас перевод ключевых трендов из отчета AFCOM. Читайте под катом!

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

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

Этот перевод статьи от learnk8s познакомит вас с принципами работы etcd, чтобы вы могли глубже понять внутреннюю работу Kubernetes и получить дополнительные инструменты для устранения неполадок в вашем кластере. Мы установим и сломаем кластер etcd с тремя нодами и узнаем, почему Kubernetes использует etcd в качестве базы данных.

Когда поднимаешь сеть на только что отстроенном объекте, в идеальном мире строители уже подготовили для тебя помещения, протянули СКС, подвели питание и сделали всё что нужно. В реальности синхронизации между поднимающими сеть интеграторами и строителями не всегда придают должное значение. Что может пойти не так?

Расскажу вам об очень показательном кейсе такого рассинхрона. Я Сергей Шульгин, эксперт по сетевым технологиям ИТ-компании К2Тех. И этой историей я как бы намекаю, зачем в крупных проектах нужен технадзор и почему мудрые заказчики кровью вписывают его в договор с интеграторами.

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

Новая звезда в мире хакерства

Как часто процесс внедрения какого-нибудь ПАК в сервер затягивается из-за того, что «выключили — внедрили — включили — всё лежит». Причём, лежит не 5 минут, а, например, 5 дней, пока вокруг бегают инженеры, пытаясь понять, почему не заводится. Порой попытки внедрить так, чтобы соответствовать требованиям регуляторов, заканчиваются неудачей с пометкой «не внедряется». О том, сколько случаев потери критической информации происходит при таких процессах, можно и не говорить. Мы и есть эти бегающие инженеры — RnD-отдел российского производителя серверов и системного интегратора «Тринити». Когда с родного ИТ-рынка ушли мировые бренды, но появилось много разной техники, часто неизвестной ни интеграторам, ни тем более заказчикам, у нашей команды значительно прибавилось работы. Ведь эту технику надо тестировать на функциональность и совместимость с нашими серверами, чем мы и занимаемся целыми днями. Вот, решили делиться результатами. 

Так вышло, что наш корпоративный хабра-блог долго стоял на паузе, но теперь всё. Начнём со средств доверенной загрузки (СДЗ) для аппаратных платформ объектов критической инфраструктуры (КИИ), которыми мы недавно укомплектовали очередную партию наших серверов.  

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

Предыстория: в наличии несколько виртуалок, с которыми долгое время не было никаких проблем. Версии - от Mojave до Monterey, они даже обновлялись штатно. Далее, при апдейте на Ventura/Sonoma ловим кернел панику - никакие рекомендации из интернета не помогли. Глаз пал в сторону хакинтоша, но как его конфигурировать под вмварь тоже оказалось не совсем понятным, поэтому и напишу этот гайд:
вводные - Ryzen 5950X, Windows 10, VMware Workstation 16.2 (была версия 16.0, пока не столкнулись в проблемой апдейта макоси).

Приветствую всех читателей Хабра! Меня зовут Михаил, я администратор DBA в компании «Автомакон». На данный момент работаю на проекте для «ВкусВилл».

Решил затронуть одну из насущных проблем, связанную с работой SQL Server, а именно со спинлоками в нем. Да, даже такой зрелый и стабильный продукт как Microsoft SQL Server иногда подкидывает неожиданные задачи. Этот кейс хорошо демонстрирует, насколько увлекательные и интересные задачи решают администраторы баз данных. 

Привет! Меня зовут Михаил Кажемский, я Lead DevOps в IT‑интеграторе Hilbert Team. В последнее время к нам часто обращаются заказчики, которым нужна помощь с организацией хранения долгосрочных метрик в российских облаках. Так как для многих эта задача сейчас актуальная, в данной статье мы с моим коллегой Денисом Бабичевым решили рассказать, как мы используем мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье вы найдете рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics.

Энто как же, вашу мать, 
Извиняюсь, понимать?
/Л. Филатов/

Представьте себе: вы приходите в офис компании, а там бухгалтер сидит над главной книгой, правой рукой попеременно откладывает ручку и щёлкает деревянными костяшками на больших счётах. Предварительные данные записаны карандашом и, если что, стираются огромным серо-голубым ластиком «Архитектор». Часть оборотных средств лежит в сейфе в кабинете бухгалтера, а за остальными он или она ходит пару раз в месяц в банк, где заполняет от руки платёжное поручение из специального ящичка. Скорее всего, вы решите, что видите сон из детства или какой-то бред (зависит от года рождения). И для 2024 года это и правда бред. Но поставить компьютеры каждому сотруднику не значит начать работать продуктивно, с другим результатом. Вот это вполне себе данность для компаний малого и даже среднего бизнеса.

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

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

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

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