Используется два подхода:
1. Классический snmp. Каждая железка опрашивается по полной, в том числе на ошибки на портах, температуры и тп. Также на ключевых каналах настроен ip sla udp-jitter. Все это собирается через PRTG. Сам PRTG уже алертит либо в мессенджер в каналы инцидент-группы, либо в Opsgenie для автоматики.
2. syslog. на всех железках включен кастомный сислог, в том числе на accounting по всем изменениям в конфиге. Все это в реальном времени экспортируется в SIEM, которая по правилу «все кроме явно исключенного» алертит в те же мессенджеры и опсжени + есть правила корреляции для ИБ.
+ heartbeat из интернета (из того же опжени) на случай если сеть вообще умерла и не позволяет мониторингу отправить об этом сообщение.
Для того чтобы достучаться до цода в случае полного падения сети есть отдельный защищенный сетевой менеджмент контур, с выделенным отдельным интернетом, фаерволом, впн и moxa подключенная консолью ко всему железу в стойке ядра.
Это исторически, но за это время мы научились иметь аптайм в хорошем цоде лучше чем предлагают классические российские (а даже и зарубежные) IaaS. Плюс для бизнеса важно было снижать риски по ФЗ-152 поэтому рассматривали всегда только российские площадки (даже учитывая необходимость только локализации ПДн).
Сейчас мы активно смотрим и пробуем PaaS/IaaS — на рынке (сейчас речь про российский рынок) стали появляться достойные решения, думаю следующая моя статья будет об опыте миграции в облако :)
Сотрудники достаточно взрослые, чтобы принимать ответственные решения. Если он пойдёт в бар - я не в праве ему это запретить. Но это не значит что он безответственно подойдёт к своей работе (например, будет употреблять алкоголь).
Речь о том, что есть достаточно гибкие возможности для обеспечения непрерывности с помощью дежурств, при этом без признаков «дежурного рабства».
Текущий SLI Lamoda (аптайм онлайн магазина, кнопки «купить») — 99.95% (это 4 часа в год)
Бизнес не готов добавить еще столько же или больше просто за счет переезда в клауд.
Моя мечта — когда российский клауд сравнится по качеству и по доступности с мировыми. Точно не в этом или следующем году, имхо. Но я верю.
Гугл клауд вполне себе подошел, мы там сделали отличный полугодовой пилот qa/dev окружения (для понимания масштабов это более сотни жирных инстансов), но по определенным причинам (спасибо ковид) были вынуждены вернуться обратно в онпрем.
В Azure у нас dev окружение нашей ERP MS Dynamics AX.
В AWS у нас есть кусочек прода — сервис, не обеспечивающий сбор персданных, и не сильно завязанный на latency между основным цодом.
Вообще вопрос клауд стратегии — это важная для нас тема.
Нельзя просто так взять и переехать в клауд (с) — думаю если бы в России был представлен хоть один из большой тройки — было бы все куда проще.
Нас волную такие вопросы как:
1. обработка и хранение при сборе персданных на территории РФ — это сложно обеспечить когда в силу специфики работы компонентов нашей платформы мы не можем просто выделить один сервис, отвечающий за сбор ПдН и оставить его в России.
2. latency — мы бьемся за каждую миллисекунду при обмене нашей сотни микросервисов, и к фрагментации по клаудам и онпрем мы пока не сильно готовы — это вызов для нас.
3. гравитация данных — сейчас наше ядро сети пропускает через себя более 120 гбит/сек — кусочки систем между клаудами могут стоить дороже по трафику, чем по compute ресурсам.
4. утилизация нашего онпрем — мы сейчас очень зрелы в нашем онпрем датацентре. миграция в клауд для ее экономической эффективности должна занять не менее срока жизненного цикла последней партии серверов.
Законодательство РФ (а именно ФЗ-152) накладывает ограничение на обработку персональных данных, предписывая осуществлять сбор и актуализацию (в понятиях Роскомнадзора) таких данных на серверах, расположенных на территории РФ, а хранение — допускается на территории стран, присоединившихся к конвенции «о ПдН». В нашей реализации (Lamoda) сбор и актуализация ПдН осуществляется в on-premise информационных системах и БД, сервера которых расположены на территории РФ. В 365 используется «копии» этих данных.
1. Классический snmp. Каждая железка опрашивается по полной, в том числе на ошибки на портах, температуры и тп. Также на ключевых каналах настроен ip sla udp-jitter. Все это собирается через PRTG. Сам PRTG уже алертит либо в мессенджер в каналы инцидент-группы, либо в Opsgenie для автоматики.
2. syslog. на всех железках включен кастомный сислог, в том числе на accounting по всем изменениям в конфиге. Все это в реальном времени экспортируется в SIEM, которая по правилу «все кроме явно исключенного» алертит в те же мессенджеры и опсжени + есть правила корреляции для ИБ.
+ heartbeat из интернета (из того же опжени) на случай если сеть вообще умерла и не позволяет мониторингу отправить об этом сообщение.
Для того чтобы достучаться до цода в случае полного падения сети есть отдельный защищенный сетевой менеджмент контур, с выделенным отдельным интернетом, фаерволом, впн и moxa подключенная консолью ко всему железу в стойке ядра.
Сейчас мы активно смотрим и пробуем PaaS/IaaS — на рынке (сейчас речь про российский рынок) стали появляться достойные решения, думаю следующая моя статья будет об опыте миграции в облако :)
Сотрудники достаточно взрослые, чтобы принимать ответственные решения. Если он пойдёт в бар - я не в праве ему это запретить. Но это не значит что он безответственно подойдёт к своей работе (например, будет употреблять алкоголь).
Речь о том, что есть достаточно гибкие возможности для обеспечения непрерывности с помощью дежурств, при этом без признаков «дежурного рабства».
Дежурный всегда имеет возможность подмениться, а вообще - профессионализм не пропьёшь )
Сравните SLA Yandex.Cloud и AWS
yandex.ru/legal/cloud_sla_compute
aws.amazon.com/ru/compute/sla
Текущий SLI Lamoda (аптайм онлайн магазина, кнопки «купить») — 99.95% (это 4 часа в год)
Бизнес не готов добавить еще столько же или больше просто за счет переезда в клауд.
Моя мечта — когда российский клауд сравнится по качеству и по доступности с мировыми. Точно не в этом или следующем году, имхо. Но я верю.
В Azure у нас dev окружение нашей ERP MS Dynamics AX.
В AWS у нас есть кусочек прода — сервис, не обеспечивающий сбор персданных, и не сильно завязанный на latency между основным цодом.
Вообще вопрос клауд стратегии — это важная для нас тема.
Нельзя просто так взять и переехать в клауд (с) — думаю если бы в России был представлен хоть один из большой тройки — было бы все куда проще.
Нас волную такие вопросы как:
1. обработка и хранение при сборе персданных на территории РФ — это сложно обеспечить когда в силу специфики работы компонентов нашей платформы мы не можем просто выделить один сервис, отвечающий за сбор ПдН и оставить его в России.
2. latency — мы бьемся за каждую миллисекунду при обмене нашей сотни микросервисов, и к фрагментации по клаудам и онпрем мы пока не сильно готовы — это вызов для нас.
3. гравитация данных — сейчас наше ядро сети пропускает через себя более 120 гбит/сек — кусочки систем между клаудами могут стоить дороже по трафику, чем по compute ресурсам.
4. утилизация нашего онпрем — мы сейчас очень зрелы в нашем онпрем датацентре. миграция в клауд для ее экономической эффективности должна занять не менее срока жизненного цикла последней партии серверов.