За последний год Amixr провели несколько десятков интервью со своими пользователями и дежурными инженерами из таких компаний, как Google, Facebook, Dropbox, SoundCloud, чтобы получить инсайты о том, что же такое эффективный инцидент-менеджмент. Кроме того, через инфраструктуру Amixr проходят более трехсот тысяч инцидентов ежемесячно.
Всю эту информацию и собственный опыт Amixr и Proto собрали в едином вебинаре в эту среду, 09 декабря в 16:00. Для участия достаточно пройти быструю регистрацию.
22 сентября Слёрм запускает новый практический курс по внедрению редких для российского рынка инструментов SRE для повышения стабильности системы. В программу интенсивов вошли темы, которые принципиально отличают работу SRE-инженеров от практик DevOps.
Поговорим про: Observability, Reliability architecture patterns, Proactive reliability testing, Chaos Engineering, Intelligent delivery of changes, Incident management.
Для начала позвольте представиться. Я — @tristan.read, фронтэнд-инженер в группе Monitor::Health GitLab'а. На прошлой неделе мне выпала честь побыть стажером у одного из наших дежурных SRE-инженеров. Целью было ежедневное наблюдение за тем, как дежурный реагирует на инциденты, и получение реального опыта работы. Нам бы хотелось, чтобы наши инженеры лучше понимали потребности пользователей функций Monitor::Health.
Мне предстояло неделю всюду следовать за SRE-инженером. То есть я присутствовал на передаче дежурства, наблюдал за теми же каналами оповещений и реагировал на инциденты, если и когда таковые имели место.
Привет, я Владислав Алмазов, директор по сопровождению информационных технологий (IT Operations) в Lamoda. Одно из направлений, за которое я отвечаю — uptime. Это количественный показатель непрерывной работы нашей платформы.
Дать возможность клиенту найти товар в каталоге, положить его в корзину, выбрать способ доставки, рассчитать скидки и оплатить — все это значит «оформить заказ». Одноименная кнопка доступна на сайте 99,95% времени в году. Оставшиеся 0,05% — это 4 часа в год, которые клиенты не замечают. Эта метрика отражает основное бизнес-требование к непрерывности самых критичных IT-систем. Час простоя для Lamoda — это потери десятков миллионов рублей.
По итогам прошлого года мы превысили план и наш uptime составил 99,96%. Дальше я расскажу, за счет чего это удалось.
Мы в Dropbox считаем, что управление инцидентами — это центральный элемент нашей системы по обеспечению надёжности. И хотя мы также используем проактивные методы, такие как хаос-инжиниринг (сhaos engineering), то, как мы реагируем на инциденты существенное влияет на опыт наших пользователей. Во время потенциального сбоя сайта или проблемы с продуктом на счету каждая минута.
Ключевые компоненты нашего процесса управления инцидентами существуют уже несколько лет, но мы видим возможности для постоянного развития в этой области. Изменения, которые мы внесли с течением времени, включают в себя как технологические, так и организационные, и процедурные улучшения.
В этом посте мы расскажем подробно о нескольких уроках, которые Dropbox вынесли из опыта управления инцидентами. Вероятнее всего, не каждый из пунктов можно найти в методичке по структуре управления инцидентами, и не стоит думать, что эти улучшения универсальны для любой компании. (Полезность этих уроков зависит от вашего технологического стека, размеров организации и других факторов). Вместо этого мы надеемся, что эта статья послужит примером, как вы можете систематически анализировать реакцию на инциденты в вашей компании и улучшать её так, чтобы удовлетворить потребности ваших пользователей.
Привет, хабр! Меня зовут Полина. Я несколько лет занималась настройкой и развитием инцидент-менеджмента для eLama.
Благодаря работе нашей команды, управление инцидентами с уровня «сообщения техдиру в мессенджере» поднялось до регламентированного и прозрачного процесса, который учитывает особенности поддерживаемого продукта и отвечает потребностям бизнеса.
В этой статье я размышляю над некоторыми вопросами, которые занимали меня саму на разных этапах работы над процессом. Например, могло ли введение регламента [работы с инцидентами] быть менее болезненным для всех сторон? О чем можно было позаботиться раньше? Возможно, кому-то будут полезны выводы, к которым я пришла.
Надежность (reliability) программного продукта всегда является одним из приоритетов компании. Особенно это актуально для ПО, превратившегося в ежедневный инструмент для своих пользователей. Они рассчитывают на заявленный функционал, поэтому любая невозможность его использования подрывает доверие, а следовательно, и желание им пользоваться.
В этой статье пойдет речь о главных инструментах Site Reliability Engineering (SRE) и о том, как они влияют на повышение надежности систем.
Меня зовут Илья Вазем, я отвечаю за всю инфраструктуру в СберМегаМаркете. Сегодня мы поговорим о наболевшем для любой команды разработки — об инцидентах. Я расскажу о том, как мы пытаемся с ними справляться и сводить возможность их появления к минимуму. А по ссылке можно посмотреть видео с моего доклада на DevOps Conf.
СберМегаМаркет, наш маркетплейс, — высоконагруженная онлайн-платформа, где более 8 000 продавцов и более 100 000 заказов в день. Мы хостимся в трех дата-центрах, у нас 250 микросервисов, 2 500 виртуальных машин. Поддерживать такую систему без серьезного подхода к инцидентам невозможно. Итак, что представляет собой этот подход в нашем случае?