Teacher
Professional
- Messages
- 2,670
- Reaction score
- 780
- Points
- 113
Более десяти лет назад концепция "безупречного" посмертного отчета изменила то, как технологические компании распознают масштабные сбои.
Джон Оллспоу, который ввел этот термин во время своей работы в Etsy, утверждал, что вскрытие направлено на то, чтобы контролировать нашу естественную реакцию на инцидент, то есть указывать пальцем: "Один из вариантов - предположить, что единственной причиной является некомпетентность, и крикнуть инженерам, чтобы они "обратили внимание!" или "будьте осторожнее!" Другой вариант - внимательно посмотреть на то, как на самом деле произошла авария, относиться к задействованным инженерам с уважением и извлечь уроки из произошедшего ".
Чему мы, в свою очередь, можем научиться из некоторых самых честных и безупречных - и публичных — вскрытий за последние несколько лет?
Инцидент начался, когда вторичная база данных GitLab, которая реплицировала первичную и выполняла функцию аварийного переключения, больше не могла синхронизировать изменения достаточно быстро из-за возросшей нагрузки. Предполагая, что упомянутую нагрузку вызвала временная спам-атака, инженеры GitLab решили вручную повторно синхронизировать базу данных-получатель, удалив ее содержимое и запустив соответствующий скрипт.
Когда процесс повторной синхронизации не удался, другой инженер попробовал процесс снова, только чтобы понять, что они запустили его против основного устройства.
Что было потеряно: Несмотря на то, что инженер остановил свою команду через две секунды, он уже удалил 300 ГБ последних пользовательских данных, что повлияло на оценки GitLab, 5000 проектов, 5000 комментариев и 700 новых учетных записей пользователей.
Как они восстановились: Поскольку инженеры только что удалили содержимое вторичной базы данных, они не могли использовать ее по назначению в качестве аварийного перехода. Что еще хуже, их ежедневные резервные копии базы данных, которые должны были загружаться на S3 каждые 24 часа, завершились неудачей. Из-за неправильной настройки электронной почты никто не получал уведомления по электронной почте, информирующие их об этом.
При любых других обстоятельствах их единственным выбором было бы восстановить данные из предыдущего снимка, который был почти 24-часовой давности. Представьте очень удачный случай: всего за 6 часов до потери данных инженер сделал снимок первичной базы данных для тестирования, непреднамеренно избавив компанию от дополнительных 18 часов потери данных.
После мучительно медленного 18-часового копирования данных по медленным сетевым дискам инженеры GitLab полностью восстановили работу сервиса.
Tarsnap управляется Колином Персивалем, который работает над FreeBSD более 20 лет и в значительной степени отвечает за внедрение этой ОС в сервис облачных вычислений EC2 Amazon. Другими словами, мало кто лучше понимал, как FreeBSD, EC2 и Amazon S3, которые хранили данные клиентов Tarsnap, могли работать вместе ... или давать сбой.
Служба мониторинга Колина уведомила его, что центральный сервер Tarsnap EC2 отключен от сети. Когда он проверил работоспособность экземпляра, он сразу же обнаружил катастрофическое повреждение файловой системы — он сразу понял, что ему придется перестраивать службу с нуля.
Что было потеряно: нет резервных копий пользователей, благодаря двум разумным решениям Колина.
Сначала Колин создал Tarsnap на файловой системе со структурой журналов. Пока он кэшировал журналы в экземпляре EC2, он хранил все данные в объектном хранилище S3, которое имеет свои собственные стратегии обеспечения устойчивости данных и восстановления. Он знал, что резервные копии пользователей Tarsnap безопасны — задача заключалась в том, чтобы снова сделать их легкодоступными.
Во-вторых, когда Колин создавал систему, он написал сценарии автоматизации, но не настроил их на запуск без присмотра. Вместо того, чтобы позволить инфраструктуре перестраиваться и перезапускать службы автоматически, он хотел сам перепроверить состояние, прежде чем позволить сценариям взять верх. Он написал: ""Предотвращение потери данных в случае поломки" гораздо важнее, чем "максимальная доступность сервиса"".
Как они восстановились: Колин запустил новый экземпляр EC2 для чтения журналов, хранящихся в S3, что заняло около 12 часов. После исправления нескольких ошибок в своем скрипте восстановления данных он смог "воспроизвести" каждую запись журнала в правильном порядке, что заняло еще 12 часов. После того, как журналы и данные блока S3 были снова должным образом связаны, Tarsnap снова заработал.
Сервис отключился не сразу — через несколько часов после того, как инженеры Roblox обнаружили единственный кластер с высокой загрузкой процессора, количество онлайн-игроков упало на 50% ниже нормы. В этом кластере размещался Consul, который работал как промежуточное программное обеспечение между многими распределенными сервисами Roblox, и когда Consul больше не мог справляться даже с уменьшившимся количеством игроков, это стало единственной точкой отказа для всего онлайн-взаимодействия.
Что было потеряно: только данные конфигурации системы. Большинство сервисов Roblox использовали другие системы хранения данных в своих локальных центрах обработки данных. Для тех, кто действительно использовал хранилище ключей-значений Consul, данные были либо сохранены после того, как инженеры решили проблемы с загрузкой и конфликтом, либо надежно кэшированы в другом месте.
Как они восстановились: Инженеры Roblox сначала попытались повторно развернуть кластер Consul на гораздо более быстром оборудовании, а затем очень медленно разрешили новым запросам поступать в систему, но ни то, ни другое не сработало.
С помощью инженеров HashiCorp и многих долгих часов команды, наконец, выявили две основные причины:
Злоумышленник пытался перемещаться по сети в горизонтальном направлении, но ему на каждом шагу отказывали в доступе. На следующий день после Дня Благодарения инженеры Atlassian окончательно удалили злоумышленника и отключили уязвимый сервер Atlassian.
В своем посмертном отчете Cloudflare заявляет, что, по их мнению, злоумышленника поддерживало национальное государство, стремящееся к широкому доступу к сети Cloudflare. Злоумышленник открыл сотни внутренних документов Confluence, относящихся к архитектуре их сети и методам управления безопасностью.
Что было потеряно: нет пользовательских данных. Архитектура нулевого доверия Cloudflare не позволила злоумышленнику перейти с сервера Atlassian на другие сервисы или получить доступ к данным клиентов.
В последнее время Atlassian фигурирует в новостях по другой причине — у их серверного предложения истек срок службы, что вынуждает организации переходить на облачные решения или решения для центров обработки данных. Во время или после этого длительного процесса инженеры понимают, что их новая платформа не обладает теми возможностями защиты данных и резервного копирования, к которым они привыкли, что вынуждает их пересмотреть свои методы обеспечения безопасности данных.
Как они восстанавливались: После загрузки злоумышленника инженеры Cloudflare изменили более 5000 производственных учетных данных, отсортировали 4893 системы и повторно обновили и перезагрузили каждую машину. Поскольку злоумышленник пытался получить доступ к новому центру обработки данных в Бразилии, Cloudflare заменила все оборудование из соображений крайней предосторожности.
Если вы можете извлечь единый урок из всех этих ситуаций, то кто-то в вашей организации, будь то амбициозный инженер или целая команда, должен владеть жизненным циклом защиты данных. Тестируйте и документируйте все, потому что только практика позволяет достичь совершенства.
Но также следует признать, что все эти инциденты произошли в собственной облачной или локальной инфраструктуре. Инженеры имели полный доступ к системам и данным для их диагностики, защиты и восстановления. Вы не можете сказать то же самое о многих облачных платформах SaaS, которые ваши коллеги используют ежедневно, таких как управление версиями кода и проектами на GitHub или развертывание прибыльных кампаний по электронной почте через Mailchimp. Если что-то случится с этими службами, вы не сможете просто использовать SSH для проверки журналов или повторной синхронизации ваших данных.
Поскольку теневые ИТ растут экспоненциально — всего за семь лет рост составил 1525%, — лучшие стратегии обеспечения непрерывности будут распространяться не на вашу инфраструктуру, а на данные SaaS, от которых зависят ваши коллеги. Вы могли бы дождаться нового вскрытия, которое даст вам надежные рекомендации относительно границ данных SaaS ... или предпринять необходимые шаги, чтобы убедиться, что это пишете не вы.
Джон Оллспоу, который ввел этот термин во время своей работы в Etsy, утверждал, что вскрытие направлено на то, чтобы контролировать нашу естественную реакцию на инцидент, то есть указывать пальцем: "Один из вариантов - предположить, что единственной причиной является некомпетентность, и крикнуть инженерам, чтобы они "обратили внимание!" или "будьте осторожнее!" Другой вариант - внимательно посмотреть на то, как на самом деле произошла авария, относиться к задействованным инженерам с уважением и извлечь уроки из произошедшего ".
Чему мы, в свою очередь, можем научиться из некоторых самых честных и безупречных - и публичных — вскрытий за последние несколько лет?
GitLab: 300 ГБ пользовательских данных исчезли за считанные секунды
Что произошло: Еще в 2017 году GitLab пережила болезненный 18-часовой сбой. Эта история и последующая честность и прозрачность GitLab существенно повлияли на то, как организации справляются с безопасностью данных сегодня.Инцидент начался, когда вторичная база данных GitLab, которая реплицировала первичную и выполняла функцию аварийного переключения, больше не могла синхронизировать изменения достаточно быстро из-за возросшей нагрузки. Предполагая, что упомянутую нагрузку вызвала временная спам-атака, инженеры GitLab решили вручную повторно синхронизировать базу данных-получатель, удалив ее содержимое и запустив соответствующий скрипт.
Когда процесс повторной синхронизации не удался, другой инженер попробовал процесс снова, только чтобы понять, что они запустили его против основного устройства.
Что было потеряно: Несмотря на то, что инженер остановил свою команду через две секунды, он уже удалил 300 ГБ последних пользовательских данных, что повлияло на оценки GitLab, 5000 проектов, 5000 комментариев и 700 новых учетных записей пользователей.
Как они восстановились: Поскольку инженеры только что удалили содержимое вторичной базы данных, они не могли использовать ее по назначению в качестве аварийного перехода. Что еще хуже, их ежедневные резервные копии базы данных, которые должны были загружаться на S3 каждые 24 часа, завершились неудачей. Из-за неправильной настройки электронной почты никто не получал уведомления по электронной почте, информирующие их об этом.
При любых других обстоятельствах их единственным выбором было бы восстановить данные из предыдущего снимка, который был почти 24-часовой давности. Представьте очень удачный случай: всего за 6 часов до потери данных инженер сделал снимок первичной базы данных для тестирования, непреднамеренно избавив компанию от дополнительных 18 часов потери данных.
После мучительно медленного 18-часового копирования данных по медленным сетевым дискам инженеры GitLab полностью восстановили работу сервиса.
Что мы узнали
- Пять причин Проанализируйте свои первопричины с помощью"". Инженеры GitLab проделали замечательную работу при вскрытии, объяснив первопричину инцидента. Дело было не в том, что инженер случайно удалил производственные данные, а скорее в том, что автоматизированная система ошибочно сообщила сотруднику GitLab о спаме — последующее удаление вызвало повышенную нагрузку и первичную<->вторичную рассинхронизацию.
- Чем глубже вы диагностируете, что пошло не так, тем лучше вы сможете построить системы безопасности данных и обеспечения непрерывности бизнеса, которые устраняют длинную цепочку неблагоприятных событий, которые могут снова вызвать сбой.
- Поделитесь своей дорожной картой улучшений. GitLab постоянно работает с предельной прозрачностью, что относится и к этому перебою в работе и потере данных. После этого инженеры создали десятки публичных проблем, в которых обсуждались их планы, например, тестирование сценариев аварийного восстановления для всех данных, которых нет в их базе данных. Обнародование этих исправлений дало их клиентам точные гарантии и позволило поделиться опытом с другими технологическими компаниями и стартапами с открытым исходным кодом.
- Для создания резервных копий требуется владелец. До этого инцидента ни один инженер GitLab не отвечал за проверку системы резервного копирования или тестирование процесса восстановления, что означало, что никто этого не делал. Инженеры GitLab быстро наделили одного из своих сотрудников правами на "остановку линии", если данные подвергались риску.
Tarsnap: выбор между безопасностью данных и доступностью
Что произошло: Однажды утром летом 2023 года эта служба резервного копирования, состоящая из одного человека, полностью отключилась.Tarsnap управляется Колином Персивалем, который работает над FreeBSD более 20 лет и в значительной степени отвечает за внедрение этой ОС в сервис облачных вычислений EC2 Amazon. Другими словами, мало кто лучше понимал, как FreeBSD, EC2 и Amazon S3, которые хранили данные клиентов Tarsnap, могли работать вместе ... или давать сбой.
Служба мониторинга Колина уведомила его, что центральный сервер Tarsnap EC2 отключен от сети. Когда он проверил работоспособность экземпляра, он сразу же обнаружил катастрофическое повреждение файловой системы — он сразу понял, что ему придется перестраивать службу с нуля.
Что было потеряно: нет резервных копий пользователей, благодаря двум разумным решениям Колина.
Сначала Колин создал Tarsnap на файловой системе со структурой журналов. Пока он кэшировал журналы в экземпляре EC2, он хранил все данные в объектном хранилище S3, которое имеет свои собственные стратегии обеспечения устойчивости данных и восстановления. Он знал, что резервные копии пользователей Tarsnap безопасны — задача заключалась в том, чтобы снова сделать их легкодоступными.
Во-вторых, когда Колин создавал систему, он написал сценарии автоматизации, но не настроил их на запуск без присмотра. Вместо того, чтобы позволить инфраструктуре перестраиваться и перезапускать службы автоматически, он хотел сам перепроверить состояние, прежде чем позволить сценариям взять верх. Он написал: ""Предотвращение потери данных в случае поломки" гораздо важнее, чем "максимальная доступность сервиса"".
Как они восстановились: Колин запустил новый экземпляр EC2 для чтения журналов, хранящихся в S3, что заняло около 12 часов. После исправления нескольких ошибок в своем скрипте восстановления данных он смог "воспроизвести" каждую запись журнала в правильном порядке, что заняло еще 12 часов. После того, как журналы и данные блока S3 были снова должным образом связаны, Tarsnap снова заработал.
Что мы узнали
- Регулярно тестируйте свой справочник по аварийному восстановлению. В публичном обсуждении сбоя и посмертного анализа пользователи Tarsnap выразили свое удивление тем, что Колин никогда не пробовал свои сценарии восстановления, которые выявили бы множество ошибок, значительно задерживающих его реакцию.
- Обновите свои процессы и конфигурации в соответствии с меняющимися технологиями. Колин признался, что никогда не обновлял свои сценарии восстановления на основе новых возможностей сервисов, на которые полагался Tarsnap, таких как S3 и EBS. Он мог прочитать данные журнала S3, используя более 250 одновременных подключений, или подготовить том EBS с более высокой пропускной способностью, чтобы сократить сроки до полного восстановления.
- Используйте человеческие проверки для сбора подробной информации о вашем состоянии, прежде чем позволить автоматизации выполнять основную работу. Невозможно точно сказать, что произошло бы, если бы Колин не включил некоторые "ремни безопасности" в процесс восстановления, но это помогло предотвратить ошибку, подобную ошибке сотрудников GitLab.
Roblox: 73 часа "раздора"
Что произошло: Примерно к Хэллоуину 2021 года в игре, в которую миллионы людей играют каждый день на инфраструктуре из 18 000 серверов и 170 000 контейнеров, произошел полномасштабный сбой.Сервис отключился не сразу — через несколько часов после того, как инженеры Roblox обнаружили единственный кластер с высокой загрузкой процессора, количество онлайн-игроков упало на 50% ниже нормы. В этом кластере размещался Consul, который работал как промежуточное программное обеспечение между многими распределенными сервисами Roblox, и когда Consul больше не мог справляться даже с уменьшившимся количеством игроков, это стало единственной точкой отказа для всего онлайн-взаимодействия.
Что было потеряно: только данные конфигурации системы. Большинство сервисов Roblox использовали другие системы хранения данных в своих локальных центрах обработки данных. Для тех, кто действительно использовал хранилище ключей-значений Consul, данные были либо сохранены после того, как инженеры решили проблемы с загрузкой и конфликтом, либо надежно кэшированы в другом месте.
Как они восстановились: Инженеры Roblox сначала попытались повторно развернуть кластер Consul на гораздо более быстром оборудовании, а затем очень медленно разрешили новым запросам поступать в систему, но ни то, ни другое не сработало.
С помощью инженеров HashiCorp и многих долгих часов команды, наконец, выявили две основные причины:
- Разногласия: Обнаружив, как долго были заблокированы записи Consul KV, команды поняли, что новая потоковая архитектура Consul находится под большой нагрузкой. Входящие данные боролись по каналам Go, разработанным для параллелизма, создавая порочный круг, который только усугублял узкое место.
- Ошибка, лежащая далеко внизу: Consul использует базу данных с открытым исходным кодом BoltDB для хранения журналов. Предполагалось регулярно очищать старые записи журнала, но по-настоящему дисковое пространство так и не освободилось, что создало большую вычислительную нагрузку для Consul.
Что мы узнали
- Избегайте систем циркулярной телеметрии. Системы телеметрии Roblox, которые контролировали кластер Consul, также зависели от этого. В своем вскрытии они признали, что могли бы действовать быстрее, имея более точные данные.
- Посмотрите на два, три или четыре шага дальше того, что вы создали для устранения первопричин. Современная инфраструктура основана на обширной цепочке поставок сторонних сервисов и программного обеспечения с открытым исходным кодом. Ваш следующий сбой может быть вызван не честной ошибкой инженера, а скорее выявлением многолетней ошибки в зависимости, удаленной из вашего кода на три шага, для запуска которой ни у кого другого не было просто подходящей среды.
Cloudflare: долгие (напряженные) выходные
Что произошло: За несколько дней до Дня благодарения 2023 года злоумышленник использовал украденные учетные данные для доступа к локальному серверу Atlassian Cloudflare, на котором работали Confluence и Jira. Вскоре после этого они использовали эти учетные данные для создания постоянного подключения к этой части глобальной инфраструктуры Cloudflare.Злоумышленник пытался перемещаться по сети в горизонтальном направлении, но ему на каждом шагу отказывали в доступе. На следующий день после Дня Благодарения инженеры Atlassian окончательно удалили злоумышленника и отключили уязвимый сервер Atlassian.
В своем посмертном отчете Cloudflare заявляет, что, по их мнению, злоумышленника поддерживало национальное государство, стремящееся к широкому доступу к сети Cloudflare. Злоумышленник открыл сотни внутренних документов Confluence, относящихся к архитектуре их сети и методам управления безопасностью.
Что было потеряно: нет пользовательских данных. Архитектура нулевого доверия Cloudflare не позволила злоумышленнику перейти с сервера Atlassian на другие сервисы или получить доступ к данным клиентов.
В последнее время Atlassian фигурирует в новостях по другой причине — у их серверного предложения истек срок службы, что вынуждает организации переходить на облачные решения или решения для центров обработки данных. Во время или после этого длительного процесса инженеры понимают, что их новая платформа не обладает теми возможностями защиты данных и резервного копирования, к которым они привыкли, что вынуждает их пересмотреть свои методы обеспечения безопасности данных.
Как они восстанавливались: После загрузки злоумышленника инженеры Cloudflare изменили более 5000 производственных учетных данных, отсортировали 4893 системы и повторно обновили и перезагрузили каждую машину. Поскольку злоумышленник пытался получить доступ к новому центру обработки данных в Бразилии, Cloudflare заменила все оборудование из соображений крайней предосторожности.
Что мы узнали
- Архитектуры нулевого доверия работают. Правильно построив авторизацию / аутентификацию, вы предотвращаете удаление данных одной скомпрометированной системой или ее функционирование в качестве отправной точки для горизонтального движения в сети.
- Несмотря на опасность, документация по-прежнему остается вашим другом. Вашим инженерам всегда нужно будет знать, как перезагрузить, восстановить или перестроить ваши службы. Ваша цель состоит в том, чтобы, даже если злоумышленник узнает все о вашей инфраструктуре из вашей внутренней документации, он все равно не смог создать или украсть учетные данные, необходимые для более глубокого проникновения.
- Безопасность SaaS легче игнорировать. Это вторжение стало возможным только потому, что инженерам Cloudflare не удалось сменить учетные данные для приложений SaaS с административным доступом к их продуктам Atlassian. Основная причина? Они полагали, что никто до сих пор не использовал указанные учетные данные, поэтому не было смысла их менять.
Что делать дальше при планировании обеспечения безопасности данных и непрерывности их работы?
Эти вскрытия, в которых подробно описывается, что именно пошло не так, и как инженеры предотвращают другие инциденты, являются не просто хорошими примерами для подражания тому, как организация может действовать честно, прозрачно и сочувствовать клиентам во время кризиса.Если вы можете извлечь единый урок из всех этих ситуаций, то кто-то в вашей организации, будь то амбициозный инженер или целая команда, должен владеть жизненным циклом защиты данных. Тестируйте и документируйте все, потому что только практика позволяет достичь совершенства.
Но также следует признать, что все эти инциденты произошли в собственной облачной или локальной инфраструктуре. Инженеры имели полный доступ к системам и данным для их диагностики, защиты и восстановления. Вы не можете сказать то же самое о многих облачных платформах SaaS, которые ваши коллеги используют ежедневно, таких как управление версиями кода и проектами на GitHub или развертывание прибыльных кампаний по электронной почте через Mailchimp. Если что-то случится с этими службами, вы не сможете просто использовать SSH для проверки журналов или повторной синхронизации ваших данных.
Поскольку теневые ИТ растут экспоненциально — всего за семь лет рост составил 1525%, — лучшие стратегии обеспечения непрерывности будут распространяться не на вашу инфраструктуру, а на данные SaaS, от которых зависят ваши коллеги. Вы могли бы дождаться нового вскрытия, которое даст вам надежные рекомендации относительно границ данных SaaS ... или предпринять необходимые шаги, чтобы убедиться, что это пишете не вы.
