The Art Of Programming — Выпуск №70 [ Drinking ] / Готовимся к новому году с alenaCPP

Поучаствовала в новогоднем подкасте The Art Of Programming. Душевно пообщались с golodnyj.

Интервью с Корринной Ю

Women in Gaming: Halo's Corrinne Yu. Корринна работает в Microsoft Game Studios, занимается архитектурой движка Halo. Интервью просто про жизнь, про программирование там маловато.

Пойду на конференцию GoingNative 2012

В начале февраля тут у нас в Редмонде будет конференция GoingNative 2012. Рассказывать будут о C++11. Обещают, что там будут Страуструп и Александреску. Схожу, посмотрю на них, потом вам расскажу.

Опубликованы исходники Doom 3

Помните, Кармак обещал опубликовать исходники Doom 3 после выхода Rage? Он свое слово держит: Doom 3 GPL source release

/*
===========================================================================

Doom 3 GPL Source Code
Copyright (C) 1999-2011 id Software LLC, a ZeniMax Media company.

Это только исходники, без данных. Данные можно взять из самой игры.

Из-за юридических проблем ему пришлось убрать оттуда кусок кода, известный как Carmack's Reverse.

Должно компиляться под Win32, Linux и MacOS.

Написано на С++, но это скорее похоже на С с классами - голые указатели, сишные массивы.

Как это обычно бывает, не все доведено до идеального состояния.

qglDisableClientState( GL_NORMAL_ARRAY );
qglDisable( GL_FRAGMENT_PROGRAM_ARB );
qglDisable( GL_VERTEX_PROGRAM_ARB );
// Fixme: Hack to get around an apparent bug in ATI drivers. Should remove as soon as it gets fixed.
qglBindProgramARB( GL_VERTEX_PROGRAM_ARB, 0 );

Как видно из кода, для отрисовки используется OpenGL. Почему-то в readme написано, что нужен DirectX. Непонятно. DirectX нужен для DirectInput.

Подменив данные и слегка поменяв код можно написать 3D-шутер своей мечты :-).

Статья The Designer's Notebook: Passion Versus Professionalism

The Designer's Notebook: Passion Versus Professionalism - статья про то, что игровой индустрии нужны скорее профессионалы, нежели энтузиасты. Но вообще там много интересного написано, что подойдет к любой индустрии.

I would much rather hire someone with professionalism than passion. Professionalism is dedication to doing a great job even if you're not the target audience.

Спасибо анонимному комментатору, который дал в комментариях ссылку на русский перевод статьи: Увлечённость или профессионализм?

via voldmar

Пост Stevey's Google Platforms Rant

Стив Йеги (я надеюсь, это произносится именно так), который работает в Гугле, случайно опубликовал в открытом доступе свою статью со сравнением API Амазона и Гугла, хвалит там SOA. Ну а также там есть немного сплетен о всяких их внутренних делах.
Эта статья стала хитом среди разработчиков, все о ней пишут, все ретвитят. В итоге статью решили из открытого доступа не убирать. Вот она: Stevey's Google Platforms Rant. Много букв.

...Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally.

ISO C++11 опубликован

Мне уже много раз присылали письма с вопросами "новый стандарт С++ уже вышел, почему у тебя в блоге ничего про это нет???". Однако, официальный пресс-релиз о выходе нового Стандарта появился только сегодня, 10.10.2011, и Твиттер начал радоваться именно сегодня. И да, у нас тут всё еще десятое, хотя у вас у многих уже 11.
Итак, можно открывать шампанское и праздновать, с обязательным зачитыванием вслух пресс-релиза.
Герб Саттер написал об этом радостном событии тут: ISO C++11 Published.
ISO, как обычно, будет продавать финальный вариант Стандарта за деньги и, как обычно, последний черновик Стандарта, который мало чем отличается от финальной версии, можно взять тут.
Ура.

Бесплатный онлайн-курс по машинному обучению

Стэнфордский университет предлагает бесплатный онлайн-курс по очень модному сегодня направлению - машинному обучению: Stanford Machine Learning class. Всё на английском, есть субтитры.
Туда входят видеолекции, вопросы по каждому разделу и упражнения, в которых надо будет писать код. Есть форум где можно задавать вопросы.
Я начала смотреть, мне нравится.

Интервью со Страуструпом на bigthink.com

Интервью с Бьярном Страуструпом.




Рассказывает про то, как он создавал С++ и про то какой это хороший язык. :-)
Считает, что каждый программист должен знать 5 языков. Страуструп советует: С++ и набрать еще из Java, Python, Ruby, JavaScript, C, C#, какой-нибудь функциональный язык.

Сказал, что использует ежедневно и Windows, и Linux.

В конце дает совет С++ разработчикам: использовать все фичи С++, в том числе посмотреть новый стандарт. "Почитайте хорошую книгу и посмотрите не застряли ли вы в 80х или 90х".

Мы все еще нанимаем

Updated 02.09.2011: Мой бывший сокурсник и нынешний коллега о работе в Майкрософте: В рекламе Микрософт я снялся в роли человека с рюкзаком и фотоаппаратом

Дорогие друзья, хочу вам напомнить, что наши рекрутеры все еще ждут ваши резюме до 31 августа. Полный текст объявления тут: Microsoft Advertising нанимает.

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

Мне не ответили, это значит, что я не подхожу?
Наши рекрутеры обычно отвечают в любом случае, даже если человек не подошел. Поэтому, если ответа нет больше недели, лучше написать им еще раз. Updated 15.09.2011: плохой совет, могут и дольше не отвечать.

По визе
Вы получаете H1B визу, по которой можете работать в США на Майкрософт. Переход в другую компанию возможен, но это определенный гемор.
Ваша жена(муж) получает H4 визу и не может работать.
Майкрософт довольно быстро начинает оформление гринкарты. В моем случае где-то через три месяца после начала работы. На сегодня оформить гринкарту для PhD несколько проще чем для магистра, оформить гринкарту для магистра несколько проще чем для бакалавра.

По медстраховке
Страховка делается на всю семью. Это большое дело, я вам скажу, медицина тут дорогая. В том числе застрахованы беременность и роды жены. Если вы сама жена, то вам будет интересно узнать, что к вашей возможной беременности отношение исключительно положительное, меня, например, этой фичей медстраховки активно заманивали.
Ребенок, родившийся на территории США, является гражданином США.
Зубы застрахованы не полностью.

Детские сады
Детские сады хорошие, но платные. У Майкрософта есть какие-то скидки. Есть двуязычные детские сады. Например, основной язык русский, но с ребенком дополнительно много занимаются английским, потому что в школе ему говорить по-английски.

Отпуск и выходные
Отпуск 3 недели в год, выходных за год получается где-то с 10 дней - это День Независимости и тому подобное. Короче, сильно меньше чем в России.
Суббота и воскресенье выходные как обычно.
Мужчинам предоставляется отпуск по уходу за ребенком (месяц, по-моему).

По переезду
Переезд полностью организован и оплачен, выплачиваются подъемные, предоставляется квартира на первое время. Иногда вместо организации переезда и квартиры просто дается мешок денег.

Съём квартиры
Однобедрумная квартира, это комната и кухня, совмещенная с гостиной, стоит от 1050 в месяц. Коммунальные платежи дороже, чем в России.
Квартира, как правило, сдается c парковочным местом. Иногда за него надо немного доплатить.
Народ живет либо в Редмонде - это деревня в хорошем смысле слова - зелень, зайчики-белочки. Все блага цивилизации присутствуют.
Либо в Беллвью - это небольшой город. Офисы Бинга находятся в Беллвью, можно близко снять квартиру и на работу ходить пешком. В Беллвью дороже.
Либо в Киркленде - он похож на Редмонд.
Очень многие, смотря на карту, видят что там рядом город Сиэтл и думают поселиться там. Вот это плохая идея. Там дороже а, главное, там пробки, по которым очень неудобно добираться на работу. У вас будет уходить на дорогу минут 40, а то и час, вместо 10-20 минут.

Общественный транспорт
Регулярно ходят автобусы (сотрудникам оплачивают проездной), есть Майкрософтовские шаттлы. Но с машиной, конечно, удобнее. На велосипеде тут ездить неплохо, много велосипедных дорожек.

Налоги
Налог у вас будет ~23-30 процентов. Налоговая система странная и мутная, причем декларацию заполняет каждый человек индивидуально. Проценты с депозитов облагаются налогом. Даже с тех депозитов, что остались в России.
Майкрософт может дать вам в помощь налоговых консультантов.


Еще в Майкрософте есть своя пенсионная программа, можно в ней поучаствовать.

В Майкрософте нет ограничений на пользование устройствами других компаний. То есть вы можете спокойно пользоваться своим iPhon'ом (несколько странный для меня, но частый вопрос).

В Беллвью, Киркленде, Редмонде очень безопасно, это чувствуется, контраст с Москвой разительный.

Во всех зданиях Майкрософта есть парковки, парковочные места для всех, а не только для особо приближенных.

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

Восемь заблуждений о распределенных вычислениях

В 1994 Питер Дейч сформулировал семь заблуждений о распределенных вычислениях, позже, в 1997, Джеймс Гослинг добавил восьмое. Это типичные ошибки, которые допускают специалисты - новички в разработке распределенных систем.
В википедии об этих заблуждениях есть статья Fallacies of Distributed Computing с ссылками на подробные объяснения. А я, как обычно, изложу их покороче.

1. Сеть надежна
   Всё время что-то ломается. Электричество выключается, сетевые провода обрываются, софт глючит.
   
2. Латентность нулевая
   Даже если пропускная способность вашей сети большая, ей нужно какое-то время, чтобы раскочегариться. Поэтому ваше прекрасное плавное AJAX приложение надо тестировать не только в корпоративной сетке.
   
3. Пропускная способность бесконечна
   Несмотря на то, что пропускная способность растет очень быстро, мы всегда найдем, чем ее загрузить: богатые интерфейсы, IP-телефония и интересные видео высокого качества.
   
4. Сеть безопасна
   Хакеры не дремлют! Повсюду малварь и DDOS атаки.
   
5. Топология никогда не меняется
   Появляются новые устройства, отключаются старые. В случае мобильных устройств топология меняется постоянно. Так что никогда не стоит думать, что передаваемые данные всегда будут ходить одним и тем же путем.
   
6. Администратор всегда только один
   Когда в разработке задействованы больше чем одна компания, а проблема где-то на стыке, решить ее бывает несколько сложнее.
   
7. Цена передачи данных нулевая
   Компьютеры, роутеры, пропускная способность и люди, которые это все обслуживают, стоят денег.
   
8. Сеть однородна
   В сети работают устройства с разными операционными системами, все время появляются новые - тут опять можно вспомнить про мобильные устройства.
   

Выступление Джона Кармака на QuakeCon 2011

Джон Кармак как обычно выступал на QuakeCon, вот видеозапись его выступления.


Расшифровку я не нашла, похоже ее пока нет.
Для тех, кто не готов слушать его полтора часа, коротенький пересказ:
Много говорил про мегатекстурирование в Rage и вообще про Rage. Как Rage получился ему нравится.
Говорил про статический анализ кода, говорит, что это вещь и надо им пользоваться. Хвалил майкрософтовский статический анализатор кода и вообще: "Microsoft Research has a lot of really smart people and they do a lot of work covering a lot of different areas."
Этот анализатор идет в комплекте с тулзами под XBOX 360, поэтому "если вы разрабатываете под 360 и не используете статический анализ, то вы совершаете ошибку.
Также упомянул PVS-studio.
Иногда ему хочется перейти на функциональные языки программирования. На Haskell, например. Но он считает, что тут будут проблемы с прозводительностью, а также с обучением и наймом людей. Поэтому остаемся с С и С++.
Ему 40 лет, ему нравится программировать и у него отлично получается. Лучше чем когда бы то ни было. (Тут сразу вспоминаются мифы про то, что программировать после 30 невозможно.)

Ну и самое главное - Код Doom 3 будет открыт в этом году. (!)

Вопросы и ответы после его выступления:


Ссылки по теме:
Твиттер Кармака
Rage и Tech5
Выступление Джона Кармака на QuakeCon 2008
Перевод выступления Кармака на Quakecon 2004

Microsoft Advertising нанимает

Microsoft Advertising нанимает. В том числе в нашу команду - Delivery Engine Team. Приходите к нам.

---

Microsoft Advertising will be hosting a recruiting event in mid-October this year to recruit top talent from all over Russia and neighboring countries specifically focusing on Software Developers of all experience levels who are interested in relocating to the U.S. At this time, we are looking to hire engineers for the roles below. ALL roles require strong coding and development experience.

• Software Development Engineer (SDE)
• Software Development Engineer II (SDE II)
• Principal SDE
• Engineering Leads

If interested – please send your information and Resume/CV to the Recruiter organizing this event: eugenial@microsoft.com by Wednesday, August 31st. We are focused on broad-based software development skills when considering potential candidates (across the board – no specific technology/product niche requirements). If you are strong in C++, C# or JAVA, we would love to hear from you!

We are looking for strong Software Development Engineers to help us with a number of hard problems in the following areas:

The Advertising Applications Team

Front End Team
Microsoft Advertising is a unified Ad Monetization platform chartered to monetize the web and other mediums (including devices) by delivering the right ads to right customers at the right time. With the migration of Yahoo advertisers, Microsoft Advertising is now the second largest advertising solution in the world. We are going through an aggressive growth cycle and plan to expand to 35 global markets over the next couple of years. As we onboard thousands of Advertisers into our system, we want to build an intuitive user experience that serves both novice and expert advertisers, an experience that is industry leading and raises the bar for end user productivity. We offer a start-up like atmosphere with tremendous opportunities for fresh perspectives.

Middle Tier Team
Excited about architecting a truly scalable and performing public web services APIs and middle-tier web services? Excited about having a revenue impact of billions of dollars and contributing to Microsoft's bottom-line? Excited to work in a team that is fueled by passion, creativity and innovation? If your answer is yes then read on!
AdCenter is the ad based monetization platform for Microsoft online business. We are the application development team responsible for developing applications used by advertisers to create and manage their millions of ad campaigns. Challenges are to engineer a highly performing, secure & scalable customer facing web services and backend services that can support millions of transactions per day. We are looking for someone who has strong coding skill in C# /C++ and ability to solve complex problems. Candidate should demonstrate good understanding in SQL fundamentals, transact-SQL and stored procedures. Experience in design and development of SOA principles based services in an online business will be an added advantage.

Back End Team
We are working to build a world class application platform fuelled by SQL Server and other data processing technologies with unprecedented scale, performance, partitioning and geo distribution with Petabyte size databases. Our OLTP systems have 10K transactions/sec and billions of transactions flowing through the system on a daily basis. You will be working with a highly motivated team on cutting edge software using agile development strategies and rapid release cycles.

The Advertising Delivery Engine Team

The Ad Delivery Platform team owns the online ad tracking and delivery system. This is a real-time platform that hosts data and code for various auction algorithms for advertisers and content publishers, click-fraud, merchant fraud, content classification, categorization, demographics prediction, search patterns. We are storing and managing TBs of information which enables us to run the auction algorithms and choose the best ads out of hundreds of thousands choices. And we do all that in just a few milliseconds, while sustaining tens of thousands of requests per second, with an uptime of 99.9%. In this environment, only the best designs and architecture will cut it. The amount of data we handle demands building, managing and monitoring a distributed system; ensuring the system health in the presence of individual failures. The Ad Delivery Engine runs 24/7/365.

The Revenue and Relevance Team

Do you want to work on technology at the heart of online monetization? The Revenue and Relevance team is looking for skilled developers- in particular, someone who has deep knowledge of large-scale data mining, machine learning, and/or quantitative analytics for online systems. As an engineer on this team, you should be able to translate design ideas into practical implementation in code, and to improve and evolve existing systems. A qualified candidate should have a degree in computer science, math, or a statistics degree and experience with software systems and/or applied research in appropriate areas of Computer Science. The algorithms we develop produce the final selection of the ads that are presented to the user upon entering the search query. As such, our algorithms are at the very heart of the Advertising technology that monetizes Bing and Yahoo. Our technology area combines systems, machine learning, data analysis, and economics --- in short, a very technically challenging area. This work makes a direct contribution to Microsoft’s bottom line.

The Business Intelligence Team
The Microsoft Advertising Business Intelligence (BI) team in Online Advertising is responsible for providing our customers with high quality analytics and reporting, giving them vital insights into their search advertising on Bing. The Reporting team within BI delivers the Middle Tier, API, and Reporting UI components that connect Microsoft Advertising BI to our customers. We are focused on providing our customers with a great user experience, a robust Middle Tier and API, and a highly reliable operational system. We work simultaneously on delivering a great product for our customers, improving our engineering processes, and growing our SDE’s skills and abilities.

Display
Microsoft: Online Services Division: Display Advertising Platform

Do you want to be part of one of the fastest growing industries in software today? Do you want to help Microsoft grow a $2 billion per year business to $5 billion? Interested in developing online services, and being part of an agile development team that ships every week? If so, then we have the right opportunity for you!

The Display Advertising group is…

• Delivering the technologies running our online display businesses: Atlas Media Console, Microsoft Media Network (MMN), AdManager, RAPT, and AdExpert - which powers the MSN portal and represented partners.
• Competing in a segment of the online advertising industry that is seeing explosive innovation and increased competition.
• Poised to make rapid advances in online advertising.
• Chartered with building the next generation of display advertiser systems.

Our Display Advertising products and services:

• Are responsible for monetizing both internal (MSN, Hotmail, MSNBC, etc.) as well as 3^rd party display properties.
• Handle 700+ billion monthly ad requests across globally dispersed data centers
• Deliver over $2 billion in annual advertising revenue.

Порядок инициализации статических переменных

Порядок инициализации глобальных статических переменных из разных единиц трансляции не определен. По-английский это называется красивым термином static initialization order fiasco. Это означает, что если у вас в разных файлах определены глобальные статические переменные x и y, то лучше, чтобы они не зависели одна от другой, а то тут могут быть неприятные сюрпризы.

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

Updated 12.07.2011:
В комментариях посоветовали два способа продлить агонию, т.е. заставить компилятор инициализировать глобальные переменные в определенном порядке.
Для GCC это init_priority
Для VC++ #pragma init_seg

P.S. Для примеров из жизни я обычно не указываю когда и кем были допущены какие-то ошибки. Это информация для того, чтобы научиться, а не для того, чтобы поглумиться. Мы все ошибаемся.

Статья "Девушки, которые выбирают программирование"

Написала статью для developers.org.ua про ситуацию с привлечением девушек в IT.
Девушки, которые выбирают программирование.
Она породила немного флейма.

Статья Lessons From FarmVille: How Zynga Uses The Cloud

Lessons From FarmVille: How Zynga Uses The Cloud - интересный пример использования облачных технологий, что называется, из жизни.

via aruslan

Перевод статьи Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region

В конце апреля 2011 года не работал облачный сервис Амазона в США. После того, как амазоновцы всё починили, они выпустили постмортем, в котором рассказали о том, что именно произошло, и что они будут делать, чтобы такое больше не происходило.
Вот он: Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region
Я его перевела. Они там налили немного воды, постоянно норовят одну и ту же фразу повторить в нескольких формулировках, это не трудности перевода, оно вот такое. И некоторые детали явно опущены.
Однако этот постмортем полезно почитать, оттуда можно почерпнуть информацию об инфраструктуре облачных сервисов о том, с какого рода проблемами сталкивается распределенный сервис. Да и учиться лучше на чужих ошибках.
Обратите внимание, что они анализируют произошедшее, а не пытаются назначить виноватых.

---

Анализ сбоя сервисов Amazon EC2 и Amazon RDS в восточном регионе США

Сейчас, когда функциональность всех сервисов полностью восстановлена, мы хотим поделиться с нашими пользователями деталями того, что произошло с вычислительным облаком компании Амазон (“EC2”) на прошлой неделе, рассказать как мы работали над восстановлением наших сервисов и что мы делаем, чтобы предотвратить повторение подобных проблем в будущем. Мы знаем, что многие из наших пользователей серьезно пострадали от этих проблем, и, как обычно в случае серьезных проблем с сервисом, мы намереваемся поделиться деталями событий и рассказать о том, как мы изменим сервис к лучшему для наших пользователей.

Сбой затронул пользователей облака EC2 в одной из Зон восточного региона США, проблемы были с частью хранилищ из Amazon Elastic Block Store (“EBS”), не обслуживались операции чтения и записи. В этом документе мы будем ссылаться на эти хранилища данных как на "зависшие диски". Те, кто пытался использовать эти сломанные диски, тоже подвисал, когда пытался читать с них или писать на них. Чтобы восстановить эти диски и стабилизировать кластер EBS в этой Зоне, мы практически все время держали отключенными все управляющие API (Create Volume, Attach Volume, Detach Volume, и Create Snapshot) для EBS в пострадавшей Зоне. Дважды в течение первого дня сбоя, деградировавший EBS кластер затронул EBS API, что привело к высокому числу ошибок и задержек при вызовах этих API во всем восточном регионе США. Как и любая сложна операционная проблема, эта была вызвана несколькими причинами, влиявшими друг на друга, и таким образом у нас есть несколько направлений, по которым надо работать, чтобы защитить наш сервис от повторения подобных проблем.

Обзор системы EBS
Понимание архитектуры EBS поможет вам лучше понять то, что произошло. EBS - это распределенное реплицированное блочное хранилище данных, которое оптимизировано под консистентность и чтение и запись с низкой латентностью из экземпляров EC2. В EBS два главных компонента. (1) Набор кластеров EBS (каждый из которых находится полностью в одной Зоне), который хранит пользовательские данные и обслуживает запросы экземпляров EC2. (2) - набор сервисов панели управления, которая используется для координации запросов пользователей и распространения их на EBS кластеры, которые работают в каждой Зоне каждого Региона.

Кластер EBS состоит из нескольких узлов EBS. Эти узлы хранят копии данных на дисках EBS и обслуживают запросы на чтение и запись, поступающие от экземпляров EC2. Для лучшей доступности и надежности, данные с дисков EBS реплицированы на несколько узлов EBS. Каждый узел EBS использует стратегию быстрого преодоления отказа, базирующуюся на технологии точка-точка, которая агрессивно создает новые реплики, если хотя бы одна из копий не синхронизирована или недоступна. Узлы кластера EBS соединены друг с другом с помощью двух сетей. Первая сеть с высокой пропускной способностью используется для обычных операций, т.е. для всех соединений с другими узлами EBS, с экземплярами EC2 и с сервисами панели управления EBS. Вторая сеть предназначена для репликации, это сеть с более низкой пропускной способностью, используется как запасная и обеспечивает узлам EBS возможность надежно соединяться с другими узлами кластера EBS и предоставляет дополнительную пропускную способность для репликации данных. Эта сеть не предназначена для того, чтобы работать со всем трафиком первой сети, она нужна для повышения надежности соединения между узлами EBS внутри кластера EBS.

Когда один узел теряет соединение с другим узлом, на который он копирует данные, он думает, что тот другой узел сломан. Чтобы сохранить надежность, он должен найти новый узел, на который он может реплицировать данные (этот процесс называется "перезеркалить"). Как часть процесса перезеркаливания, узел EBS ищет в своем кластере EBS другой узел с достаточными количеством свободного места, устанавливает с ним связь и передает данные. В нормально работающем кластере процесс поиска места для новой реплики занимает миллисекунды. В процессе перезеркаливания данных все узлы, которые имеют копии данных, будут хранить их до тех пор пока они не получат подтверждение, что другой узел теперь владеет их порцией. Это предоставляет новый уровень защиты от потери данных пользователей. Также, когда данные на диске пользователя перезеркаливаются, доступ к данным блокируется до тех пор пока система не идентифицирует новую первичную (или доступную для записи) реплику. Это требуется для обеспечения консистентности данных на диске EBS в случае возникновения ошибок. Пока происходит этот процесс, с точки зрения экземпляра EC2, пытающегося делать операцию ввода-вывода на диск, диск кажется "зависшим".

В дополнение к кластеру EBS, есть набор сервисов панели управления, который принимает запросы пользователя и передает их на нужный кластер EBS. Есть один набор сервисов панели управления EBS на один EC2-регион, но сама панель управления распределена по Зонам, чтобы обеспечить доступность и устойчивость к сбоям. Эти сервисы панели управления также являются авторитетами для кластеров EBS, когда те выбирают первичную реплику для каждого диска кластера (для консистентности, у каждого диска в каждый момент времени должна быть только одна первичная реплика). В панели управления несколько сервисов, мы будем на них на все ссылаться как на "панель управления EBS".

Первый сбой
21-го апреля в 0:47 по дневному тихоокеанскому времени в одной из Зон восточного региона США была произведена смена настроек сети, это была часть обычной работы по масштабированию AWS. Целью смены настроек было увеличение пропускной способности первичной сети. Один из стандартных шагов смены настроек - убрать трафик с одного из роутеров с резервированием в первичной сети EBS, чтобы можно было апгрейдиться. Переключение трафика было произведено некорректно и вместо того, чтобы перенаправить трафик на другой роутер в первичной сети, трафик был перенаправлен в сеть EBS с меньшей пропускной способностью. Для части кластера EBS в пострадавшей Зоне это означало, что у него теперь нет ни правильно функционирующей первичной сети, ни вторичной сети, потому что трафик был специально перенаправлен из первичной сети, а вторичная сеть не могла справиться со всем тем трафиком, что в нее пришел. В результате многие узлы EBS в пострадавшей Зоне были полностью изолированы от других узлов кластера EBS. В отличие от случая нормального прерывания работы сети, это изменение отключило одновременно и первичную, и вторичную сети, затронутые узлы были полностью изолированы друг от друга.

Когда случилась эта проблема со связностью сети, большое число узлов EBS на одном кластере EBS потеряло связь со своими репликами. Когда все вернули обратно и связность была восстановлена, эти узлы тут же начали поиск доступного серверного пространства в кластере EBS, куда бы они могли перезеркалить данные. Повторимся, что в нормально функционирующем кластере это занимает миллисекунды. В данном же случае, из-за того, что одновременно было затронуто много дисков, свободное место на кластере EBS быстро закончилось, многие узлы так и остались зависшими, они продолжали в цикле искать в кластере свободное место. Это быстро привело к "шторму перезеркаливания": большое число дисков зависли, в то время как узлы искали в кластере свободное место, которое им было нужно для реплик. В этот момент примерно 13% дисков в пострадавшей зоне были повисшими.

После вышеописанной цепочки событий деградация кластера EBS немедленно отразилась на панели управления EBS. Когда кластер EBS входит в шторм перезеркаливания и расходует все доступное свободное место, кластер больше не может отвечать на вызов API "CreateVolume". Так как панель управления EBS (а в особенности вызов функции API CreateVolume) была сконфигурирована с большим таймаутом, эти медленные API вызовы начали накапливаться, что привело к голоданию потоков в панели управления EBS. В панели управления EBS есть региональный пул потоков, которые можно использовать для обслуживания запросов. Когда все эти потоки были переполнены большим числом накопившихся запросов, панель управления EBS не могла больше обслуживать API запросы и начала также отказывать API запросам из других Зон этого Региона. 21 апреля в 2:40 команда накатила изменение, которое отключало все новые запросы CreateVolume в пострадавшей Зоне, и к 2:50 уровень ошибок и задержек для всех вызовов API, относящихся к EBS, был восстановлен.

EBS кластер продолжил деградировать по двум причинам. Во-первых, узлы, которые не могли найти новые узлы, не прекращали поиски достаточно быстро, когда они не могли найти свободное место. Вместо этого они продолжали искать. Также в коде узлов EBS было состояние гонки, которое, с очень низкой вероятностью, приводило к их отказу когда они последовательно закрывали большое количество запросов на копирование. На нормально работающем кластере EBS эта проблема привела бы к небольшому числу падений узлов, если бы вообще к ним привела. Однако, во время шторма перезеркаливания количество попыток соединения было очень высоко, и эта проблема начала проявляться чаще. Узлы начали отказывать из-за этого бага, это привело к тому, что еще большему количеству дисков потребовалось перезеркаливание. Это привело к увеличению числа зависших дисков и добавило еще запросов к шторму перезеркаливания.

К 5:30 увеличилось количество ошибок и задержек для вызовов EBS API в Регионе. Когда данные с дисков должны быть перезеркалены, начинаются переговоры между экземплярами EC2, узлами EBS с данными и панелью управления EBS (которая выступает главной в этом процессе), так что только одна копия данных является первичной репликой и экземпляр EC2 распознает ее как место, куда надо слать все запросы на доступ. Это обеспечивает консистентность дисков EBS. По мере того, как все больше узлов EBS начали отказывать из-за состояния гонки, описанного выше, объем переговоров с панелью управления EBS увеличился. Так как данные не были успешно перезеркалены, число подобных вызовов увеличивалось по мере прихода новых запросов. Нагрузка привела к отказу панели управления EBS и это опять затронуло вызовы EBS API по всему Региону. В 8:20 команда начала отключать все соединения между деградировавшим кластером EBS в пострадавшей Зоне и панелью управления EBS. Несмотря на то, что это заблокировало все доступы EBS API в Зоне (мы обсудим восстановление в следующей секции), в целом задержки и уровень ошибок вернулись к нормальным для EBS API данного Региона.

Подавляющее большинство дисков деградировавшего кластера EBS все еще функционировали нормально и нашей целью было восстановить кластер без того, чтобы затронуть еще больше дисков. В 11:30 команда нашла как прекратить бессмысленные попытки серверов EBS из деградировавшего кластера EBS связаться друг с другом (в тот момент на них все равно не было свободного места), не затрагивания при этом другие важные коммуникации между узлами кластера. После того, как это изменение было произведено, кластер прекратил деградировать дальше и ушел риск того, что еще какие-то диски повиснут. Перед тем как это изменение было произведено, серверы, отказавшие по причине состояния гонки, добавили еще 5% к общему числу зависших дисков в Зоне. Однако, хотя и медленно, но перезеркаливание дисков продолжилось, по мере того как место понемногу освобождалось и некоторые зависшие диски отвисли. Общим результатом того изменения было то, что общее количество зависших дисков в пострадавшей Зоне стало 13%.

До полудня 21 апреля пользователи замечали возросшее число ошибок при попытках запустить новые EBS-бакеты экземпляров EC2 в других Зонах, не в той, которая пострадала. Это продолжалось в течение примерно 11 часов, от начала отказа до полудня 21 апреля. Кроме периодов проблем с API, описанных выше, пользователи могли создать EBS-бакеты экземпляров EC2, но количество ошибок и задержки было больше обычного. Новые запуски EBS-бакетов зависят от одного API в панели управления EBS, которое нужно для того, чтобы подключать новые образы дисков. Изначально наша система мониторинга недостаточно хорошо умела работать с этим вызовом API панели управления EBS и ошибки запусков были закрыты общей ошибкой деградировавшего кластера EBS. В 11:30 изменение в панели управления EBS починило это проблему и задержки и уровень ошибок для новых EBS-бакетов экземпляров EC2 быстро снизились и вернулись к почти нормальному уровню к полудню.


Восстановление EBS в затронутой Зоне
К 12:04 21 апреля сбой был изолирован в одной пострадавшей Зоне и деградировавший кластер EBS был стабилизирован. Во всех остальных зонах API работали хорошо и больше не было новых зависших дисков. Теперь нашей целью было завершить восстановление. Примерно 13% дисков в Зоне оставались зависшими и API EBS были отключены в пострадавшей Зоне. Основным приоритетом стало подключение и выведение онлайн дополнительных объемов для хранения данных, что позволило бы зависшим дискам найти достаточно места для создания новых реплик.

Перед командой стояло две проблемы, которые не давали подключить дополнительные объемы. Первая, когда узел отказывает, кластер EBS не будет использовать отказавший узел до тех пор, пока каждая реплика не перезеркалена успешно. Это было осознанное решение, оно нужно было для того, чтобы мы могли восстановить данные, если кластер перестает вести себя как спроектирован. Так как мы не хотели использовать отказавшие диски в других целях до тех пор пока мы не будем уверены, что мы сможем восстановить данные пользователей, оказавшиеся на отказавших узлах, команде пришлось установить много новых дисков, чтобы заменить те отказавшие диски. Это довольно долгий процесс, надо было физически собрать все лишние диски по всему восточному региону США и установить их на деградировавший EBS кластер. И вторая: так как были произведены изменения с целью уменьшить количество коммуникаций между узлами, используемые этими узлами для того, чтобы найти свободное место (что в итоге стабилизировало кластер, как описано выше) у команды были проблемы с добавлением новых дисков в кластер. Команде пришлось очень аккуратно вносить изменения в каналы коммуникации, чтобы новые серверы заработали, не загружая при этом старые запросами, которые те все равно не могли бы обслужить. Этот процесс занял больше времени, чем мы ожидали, так как нашей команде пришлось решить ряд проблем при работе с отключенными коммуникациями. Примерно в два часа ночи 22-го апреля команда смогла добавить значительные дисковые объемы и начала просматривать невыполненные запросы на репликацию. Диски консистентно восстановились в течение последующих девяти часов и все, кроме 2.2% дискового объема затронутой Зоны были восстановлены к 12:30 22-го апреля. Пока восстановленные диски полностью реплицировались, не все они мгновенно становились отвисшими с точки зрения прикрепленных экземпляров EC2, потому что некоторые из них были заблокированы, ожидая пока можно будет подключиться к панели управления EBS, чтобы можно было переподключиться к экземпляру EC2 и выбрать новую копию для записи.

После того, как к кластеру были добавлены достаточные объемы, команда начала работать над тем, чтобы настроить доступ API к панели управления EBS затронутой Зоны и восстановить доступ к оставшимся зависшим дискам. Там накопилось много запросов на смену состояний, которые надо было передать из деградировавших узлов EBS на панель управления EBS и наоборот. Это пришлось делать постепенно, чтобы это не отразилось на восстановленных дисках и на панели управления EBS. Сначала мы пытались включить API в пострадавшей Зоне путем передачи этих состояний таким образом, чтобы не перегрузить панель управления EBS. Мы также начали создавать отдельный экземпляр панели управления EBS, который был бы отделен от пострадавшей Зоны и чтобы тогда передача состояний не отражалась на других Зонах Региона. Мы быстро настроили каналы, но не смогли передать через них правильные запросы и стабилизировать систему. С вечера 22 апреля по утро 23-го мы работали над улучшением этих каналов. К утру субботы мы закончили нашу работу над отдельный панелью управления EBS и над каналами. Первые тесты трафика по направлению к панели управления EBS были успешными и вскоре после 11:30 23-го апреля мы начали потихоньку обрабатывать накопившиеся запросы. К 15:35 мы закончили настраивать связь между панелью управления EBS и деградировавшей Зоной. Это позволило большинству оставшихся дисков, которые все еще ждали ответа панели управления EBS, определить в какую именно реплику будет производиться запись, и прикрепленные к ним экземпляры EC2 могли опять их использовать. В 18:15 23-го апреля, API доступ к ресурсам EBS в пострадавшей Зоне был восстановлен.

С открытием API доступа к пострадавшей Зоне, API теперь работали во всех Зонах Региона. Восстановление оставшихся 2.2% пострадавших дисков потребовало больше ручной работы. В самом начале команда скопировала эти диски в бэкапы S3, это было сделано в качестве меры предосторожности, чтобы не потерять информацию. К тому моменту, команда закончила разрабатывать и тестировать код, который восстанавливал данные из этих копий и запустила процесс восстановления на ночь. в 12:30 24 апреля мы закончили работы с данными, которые мы таким образом могли восстановить и восстановили все, кроме 1.04% пострадавших дисков. В этот момент команда начала изучать оставшиеся диски, которые показывали хардварные ошибки, и с которых мы не могли снять копии. В 15:00 команда начала восстанавливать и их. В итоге, 0.07% дисков в пострадавшей Зоне не могли быть восстановлены в консистентном состоянии.


Последствия для Реляционных сервисов базы данных Amazon (RDS)
Проблемы возникли не только с экземплярами EC2, также был затронут реляционный сервис баз данных (RDS). RDS хранит в EBS базы данных и логи, и в результате часть баз данных RDS, хостящихся в пострадавшей Зоне, была недоступна.

Пользователи могут выбирать, работать ли им с экземплярами RDS в одной Зоне ("одна-AZ") или копировать на несколько Зон ("мульти-AZ"). Сбои в Зоне затрагивают экземпляры базы данных типа одна-AZ. В данном случае, экземпляр базы данных типа одна-AZ был бы поврежден, если завис хотя бы один из дисков EBS, на которые он ссылается. В первой пострадавшей зоне, в пике 45% одна-AZ экземпляров были затронуты зависшим вводом-выводом. Пострадавшая часть RDS несколько больше пострадавшей части EBS, потому что экземпляр базы данных RDS может использовать несколько дисков EBS. Это увеличивает суммарную пропускную способностью ввода-вывода базы данных в нормальных условиях, но это же и означает, что зависший ввод-вывод на одном любом диске базы данных типа одна-AZ может сделать ее нерабочей до тех пор, пока диск не восстановлен. Процент зависших баз типа одна-AZ в пострадавшей Зоне постепенно уменьшался по мере восстановления EBS. Процент зависших экземпляров базы данных типа одна-AZ в пострадавшей Зоне снизился до 41.0% через 24 часа, до 23.5% через 36 часов, до 14.6% через 48 часов. В течение выходных все восстановилось до конца. Несмотря на то, что мы восстановили практически все пострадавшие базы данных, 0.4% экземпляров баз данных типа одна-AZ в пострадавшей Зоне располагались на диске EBS, который восстановить было нельзя. Для этих баз данных пользователи, у которых автоматический бэкап был включен (а он включен по умолчанию), имели опцию начать восстановление базы данных из бэкапа.

Базы данных типа мульти-AZ более устойчивы к сбоям, поскольку синхронно копируют данные между двумя репликами базы данных в различных Зонах. В случае, если первичная реплика недоступна, RDS автоматически это определяет и переключается на вторичную реплику. 2.5% экземпляров баз данных типа мульти-AZ в восточном регионе США не смогли автоматически переключиться, после того как завис ввод-вывод. Основной причиной этого было то, что отключение сети (той, что соединяла первичную от вторичную реплики) и произошедшее сразу после этого зависание ввода-вывода на первичной реплике вызвали к жизни ранее не замеченный нами баг. Этот баг оставлял первичную реплику в изолированном состоянии, в таком случае наш мониторящий агент не мог безопасно переключиться на вторичную реплику без риска потери данных, здесь требовалось вмешательство человека. Сейчас мы активно работаем над починкой этого бага.

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

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

Эффект на несколько Зон
EC2 предоставляет два важных базовых блока доступна: Регионы и Зоны. Согласно дизайну, Регионы совершенно отдельные инсталляции нашей инфраструктуры. Регионы полностью изолированы друг от друга и предоставляют самый высокий уровень независимости. Многие пользователи используют несколько Регионов EC2, чтобы получить устойчивость к ошибкам самого высокого уровня. Однако, если вы хотите переместить данные между Регионами, вам надо делать это самостоятельно с помощью ваших приложений, так как мы не копируем данные между Регионами по запросам пользователей. Вы также должны использовать различные наборы API для управления каждым Регионом. Регионы являются важными базовыми единицами доступности для пользователей, но со стороны разработчиков приложений требуются дополнительные усилия, чтобы использовать преимущества этой изоляции. Мы предоставляем Зоны внутри Регионов, чтобы помочь разработчикам легко строить приложения, устойчивые к ошибкам. Физически и логически инфраструктуры Зон отделены друг от друга, таким образом, чтобы они были независимыми и при этом предоставляли пользователям высокоскоростную сеть с низкой латентностью, простые пути репликации данных и полный и непротиворечивый набор управляющих API. Например, с приложений, запущенных внутри Региона, пользователи могут снимать EBS снэпшоты, которые могут быть восстановлены в любой Зоне и могут программно манипулировать EC2 и EBS ресурсами используя одинаковые API. Мы предоставляем эту слабую связность, потому что она позволяет пользователям легко строить высоконадежные приложения.

Случившиеся привело к двум последствиям. Во-первых, это отразилось на приложениях, запущенных в пострадавшей Зоне, потому что пострадавшие диски EBS зависли. Архитектура сервисов EBS устроена таким образом, что влияние на запущенные образы было ограничено Зоной. В результате пользователи, которые пишут свои приложения таким образом, чтобы использовать несколько Зон, практически ничего не заметили. Некоторые пользователи сообщали, что у них зависли диски EBS в других Зонах, не в той, которая пострадала в четверг. Наша система мониторинга явно показывает эффект шторма перезеркаливания на панели управления EBS и на дисках в пострадавшей Зоне, она не показывала значительного влияния этого на диски EBS в других Зонах Региона. Хотя мы действительно видим, что в не пострадавших Зонах было чуть больше зависших дисков чем обычно, но все равно это очень малое число. Пиковое значение зависших дисков в процентах, которое мы видели в Регионе за пределами пострадавшей Зоны было менее 0.07%. Мы расследовали число это зависших дисков. Чуть большее, чем обычно, число зависших дисков в этих не пострадавших зонах было вызвано задержками в восстановлении из нормального перезеркаливания, потому что возросла латентность и возросло число ошибок в панели управления EBS, как это описано выше; всегда есть какое-то число процессов перезеркаливания в каждый момент времени. Также мы думаем, что работа, описанная ниже, направленная на то, чтобы изолировать панель управления EBS, сможет предотвратить даже такой, не намного больше, чем обычно, уровень ошибок, если случится что-нибудь подобное.


Хотя приложения пользователей, которые использовали преимущества архитектуры нескольких Зон (мульти-AZ), не пострадали от этого сбоя, проблемы с панелью управления EBS повлияли на возможность создавать диски EBS в Регионе и управлять ими. Одно из преимуществ EC2 - это возможность быстро заменять сломанные ресурсы. Когда панель управления EBS деградировала до такого состояния, что стала недоступна, пользователям с пострадавшими дисками стало сложно заменять их диски или загруженные с EBS образы в других, здоровых, Зонах. Наша главная задача - предотвратить подобное в дальнейшем.

Несмотря на то, что мы предоставляем нашим пользователям определенный уровень слабой связности, нашей целью было сделать Зоны неотличимыми от совершенно независимых. Наша панель управления EBS разработана таким образом, чтобы пользователи могли иметь доступ к ресурсам в нескольких Зонах, при этом быть устойчивыми к ошибкам в отдельных зонах. Это событие показало нам, что мы должны и в дальнейшем работать над достижением этой цели. Мы сделаем три вещи, которые предотвратят влияние отдельных Зон на панель управления EBS нескольких Зон. Первое, что мы сделаем, - мы немедленно улучшим нашу логику таймаутов, чтобы предотвратить исчерпание потоков, когда один из кластеров в Зоне слишком долго обрабатывает запросы. Это могло бы предотвратить проблемы с API c 0:50 до 2:40 21 апреля. Чтобы решить вторую проблему, возникшую с API, мы добавим к нашей панели управления EBS возможность знать больше о Зонах и разумно сбрасывать лишнюю нагрузку, когда превышена максимальная нагрузка. Подобное уже есть в нашей системе. Также мы хотим перенести кое-что из нашей панели управления EBS в наши сервисы кластеров EBS. Перенеся часть функциональности из панели управления EBS и развертывая эти сервисы на кластерах EBS (которые работают в той же Зоне, что и кластер EBS, который они поддерживают), мы сможем предоставить лучшую изоляцию Зон от панели управления EBS.


Упростить использование преимуществ нескольких Зон
Мы также намерены упростить возможность использования нескольких Зон. Во-первых, мы предложим несколько Зон для всех наших сервисов, включая виртуальное приватное облако Amazon (VPC). Сегодня пользователи VPC имеют доступ только к одной Зоне. Мы пересмотрим наших планы и дадим пользователям VPC доступ к нескольким Зонам как можно быстрее. Таким образом пользователи VPC смогут строить приложения с выским уровнем доступности используя несколько Зон, точно так же как это EC2 пользователи, не использующие VPC.

Также мы обнаружили, что нам следуем упросить процесс выкатывания приложений на мульти-AZ. Некоторые приложения пользователей (или значительные части этих приложений, например, базы данных), выкладываются только в одной Зоне. Образы других приложений рассредоточены по нескольким Зонам, но все же имеют единые точки отказа в одной Зоне. В таких случаях расходы на оперирование могут негативно сказаться на досупности приложения, в то время как при правильном процессе выкладки на несколько зон приложение должно продолжать работать как будто ничего не случилось. Мы предоставим пользователям более хорошие средства работы по созданию мульти-AZ приложений, и падение всей Зоны целиком не отразится на доступности приложений. Мы знаем, что должны помочь пользователям разрабатывать их приложения используя обычные паттерны проектирования. В данном случае, некоторые пользователи серьезно пострадали, в том время как у других какие-то ресурсы пострадали, но при этом на их приложениях это практически никак не отразилось.

С тем, чтобы продолжить более тесно работать с нашими пользователями и партнерами над лучшими практиками архитектуры в облаке, мы организуем ряд вебинаров стартуя со второго мая. Первая тема, которую мы затронем, будет "дизайн приложений, устойчивых к ошибкам", "архитектура в облаке", и "лучшие практики веб-хостинга". Мы собираемся добавить больше тем в течение ближайших недель и мы продолжим делать это часто и постоянно. В течение ближайших двух недель вебинары будут проводиться по нескольку раз за день для наших пользователей, работающих в различных часовых поясах. Отдельно мы проведем значительное количество вебинаров, посвященных ответам на ваши вопросы. Также будут организованы дискуссии для наших пользователей и партнеров. Это вебинары, а также серия статей по лучшим практикам дизайна архитектуры для AWS облака, доступны на нашем AWS сайте в разделе Архитектура. Мы также продолжим предоставлять дополнительные сервисы такие как S3, SimleDB и мульти-AZ RDS, которые предоставляют автоматическую балансировку для мульти-AZ таким образом, что пользователи могут получать пользу от нескольких Зон не делая ничего особенного сложного в их приложениях.


Сделать восстановление быстрее
Мы займемся над улучшением визуализации, контроля и автоматизации восставновления дисков в кластере EBS. У нас есть набор утилит для управления кластером EBS, но те утилиты, что наша команда использовала для восстановления кластера, будут встроенны напрямую в узлы EBS. Мы также автоматизируем модели восстановления, которые мы использовали для восстановления различных дисков. Это бы сэкономило нам много времени во время восстановления. Мы также посмотрим что можно сделать, чтобы диск продолжал функционировать в периоды деградации кластера, включения возможность снимать полную копию с зависшего диска. Если бы у пользователей была такая возможность, они могли бы гораздо проще восстановить их приложения в других Зонах Региона.


Улучшить коммуникации и утилиты по мониторингу состояния сервисов во время различных происшествий
В дополнение к различным техническим улучшениям по результатам произошедшего, мы также решили кое-что улучшить с общении с пользователями. Мы хотим сделать наше общение с пользователями более частым и содержащим большем информации. Мы понимаем, что во время сбоя пользователи хотят знать о происходящем настолько подробно, насколько это возможно: как долго будет занимать починка и что мы делаем, чтобы предотвратить повторение подобного. Большая часть команды AWS, включая всех старших специалистов, была вовлечена в процесс исследования и починки. Изначально мы были сфокусированы на том, чтобы продумать как решить текущие проблемы пользователей, а не над тем, чтобы определить основные причины того, что случилось. Мы думали, что сфокусировать наши усилия на решении, а не на проблеме, правильнее по отношению к нашим пользователям, и это помогло нам быстрее вернуть сервисы в нормальное состояние. Мы оповещали пользователей, когда у нас была новая информация и когда мы были уверены, что это информаци верна, что это не догадки, мы знали, что как только мы вернем все наши сервисы обратно в нормальное состояние, мы немедленно приступим к фазе сбора информации и анализу, чтобы сделать вот этот постмортем.

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

Мы также могли бы лучше рассказывать пользователzм о том, пострадали ли их ресурсы, мы также разрабатываем утилиты для разработчиков, чтобы они могли посмотреть с помощью вызовов API, все ли в порядке с их экземплярами.


Компенсация пострадавшим пользователям
Пользователям, у которых в пострадавшей Зоне были диски EBS или базы данных RDS, вне зависимости от того, пострадали ли их ресурсы и приложения или нет, мы предоставляем десятидневный кредит равный 100% использования их дисков EBS, образов EC2 и баз данных RDS, которые были запущены в затронутой Зjне. Эти пользователи не должны ничего делать, чтобы получить этот кредит, он будет автоматически включен в их следующий счет AWS. Пользователи могут узнать, будет ли им предоставлен этот кредит или нет, залогинившись в их аккаунт AWS.

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

Искренне ваша,
команда AWS

---

Ссылки по теме:
Amazon Elastic Compute Cloud
Retrospect on recent AWS outage and Resilient Cloud-Based Architecture
Почему в конце декабря не работал Skype
Facebook - More Details on Today's Outage - про отключение Фейсбука в сентябре 2010.

Радио-Т 238

Внезапно поучаствовала в подкасте Радио-Т. Выпуск 238.

- Алён, приходи к нам!
- Эмм, ну хорошо, давай...
- Отлично, ты в эфире через полчаса!

На мой взгляд, самое интересное там - это рассказ Umputun'а про использование Protocol Buffers.

Inception in C

via Moriarty

Доклад Handling ridiculous amounts of data with probabilistic data structures

Полное название доклада PyCon 2011: Handling ridiculous amounts of data with probabilistic data structures. Но вообще это об использовании фильтра Блума в биоинформатике. Всего 20 минут.

Начались продажи iPad2

Пока в Москве была ночь... у нас тут был день! И начались продажи iPad2.

Мой коллега Артём не поленился сходить в соседний магазин и заснять толпы людей, алчущих iPad2.

Очередь.


Видео с куском очереди.


Все апплодируют



Артёму спасибо :-)

Критика boost::serialize

boost::serialization hell - эмоциональный пост про проблемы, возникающие при использовании boost::serialize.
Будет полезно тем, кому в проекте нужна сериализация и кто рассматривает boost::serialize как один из вариантов.

Baidu maps

Китайский Baidu - один из национальных поисковиков, который обходит Google по популярности. Точно также Яндекс популярнее Google в России.
И у Baidu есть свои карты. И они стоят того, чтобы на них взглянуть.





(via @igrigorik)

Статья про управление памятью

Alternatives to malloc and new - статья про то, как происходит аллокация памяти, как и почему это ведет к фрагментации. И про то, как можно с этим бороться - управлять памятью самостоятельно. Всё с красивыми и понятными картинками.

Это актуально в разработке игр, например.

Статьи по теме:
Virtual Addressing 101
Start Pre-allocating And Stop Worrying
Region-based memory management

Компьютер IBM играет в "Свою игру"

И неплохо играет, кстати. В комментариях на YouTube часто вспоминают SkyNet :-)





Вся игра целиком здесь.


via dirty.ru

Статья с сравнением ++it и it++

В статье Есть ли практический смысл использовать для итераторов префиксный оператор инкремента ++it, вместо постфиксного it++ Андрей Карпов ставит эксперименты с префиксными и постфисными операторами.

Про работу в Майкрософт

Вопросы по поводу моего устройства в Майкрософт поступают со страшной силой, давайте я расскажу об этом что ли.
Самый часто задаваемый вопрос "Как ты попала в Майкрософт?". Майкрософт летом проводил собеседования в Москве. Я прошла сначала телефонное интервью, потом очное. Также меня спрашивают "было ли сложно?". Прямо даже и не знаю как ответить на этот вопрос. Я пришла, мне задали какие-то вопросы, я на них как-то ответила, потом мне прислали job offer. Вроде несложно :-).

Примеры вопросов можно найти поиском по "Microsoft interview questions". Их там будет много.

Оформление визы, перевозка специалиста (это называется relocation), адаптация специалиста на месте - процесс давно обкатанный. Всё тут хорошо, короче говоря.

Работаю я в городе Бельвью, он находится рядом с Сиэттлом. Сижу в здоровом высотном здании. Работаю в команде Bing Advertising, это контекстная реклама. Программирую на С++. :-)
Меня спрашивали отдельные ли у нас офисы. В основном да, отдельные. Но есть те, кто сидит по двое, я сижу вдвоем с китайцем. Веселый такой парень. Еще видела одну комнату где сидят человек шесть.

Но что-то мне подсказывает, что вас скорее интересует не то как я попала в Майкрософт, а то, как вам попасть в Майкрософт. Найм продолжается, есть разные вакансии:

Для специалистов с опытом вакансии можно найти на careers.microsoft.com. Его читают, на резюме реагируют. Вот вакансии моей группы: раз, два и три. (Updated 16.6.2011 - все эти вакансии закрыты, но есть другие)

Алексей Пахунов периодически публикует у себя на блоге вакансии.

Для выпускников
Microsoft проведёт очередной набор студентов и выпускников из России, Беларуси и Украины.

Для студентов есть программа стажировки (internship). Поговорила с теми, кто проходил по этой программе, народ доволен. Им оплачивали переезд и платили нормальные деньги во время работы (часто стажерам либо вообще не платят, либо платят смешные деньги). Вполне себе реально приехать по этой программе иностранному студенту, российскому студенту в том числе. Вроде еще не поздно подаваться на этот год (лето 2011).


Есть еще Microsoft JobsBlog, там бывает полезная информация про прохождение собеседований.


По поводу прохождения собеседований вообще, не только в Майкрософт. Очень многие мои знакомые хотели, но не прошли. Знаете почему? Они не пришли на собеседование. Всегда находятся отговорки "мне надо еще тут подучить", "мне надо еще это доделать". Всегда есть чего подучить и чего доделать. Оформление визы занимает много времени, вы сто раз успеете все доделать. И всегда боязно, что не возьмут, это бьет по самооценке, да и друганы не поймут. Ну тут я могу сказать, что отказ на собеседовании дело обычное, а друганам можно об этом не рассказывать :-).

P.S. Я не буду плодить кучу постов, а по результатам вопросов буду дописывать сюда. И еще фоток кину.

Bufferbloat

Новый термин bufferbloat появился с легкой руки Джима Гетти (Jim Getty) после серии постов на его блоге в декабре 2010 - январе 2011.
The criminal mastermind: bufferbloat!
Whose house is of glasse, must not throw stones at another.
Bufferbloat in 802.11 and 3G Networks
Там рассказывается о том, что буферизация данных в Интернете приводит к латентности, которой быть не должно. И наши интернеты не так быстры как могли бы быть. И ситуация медленно меняется к худшему.
Плохо это, например, тем, что такие сервисы как Skype не могут качественно работать при такой латентности.

bufferbloat (and a Net Neutrality rant in the footnotes) - пост другого автора на эту же тему, рассказывает о том как эту проблему можно частично решить. Интересен еще и тем, что там упоминается программа написанная русским гениальным программистом. Это приятно.

via Maniac

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

Приняла участие в подкасте Радио Т

На подкасте Радио Т номер 222 поговорили о языках программирования вообще и о C++ в частности.
Размышления на тему судьбы языка С++ стали особенно актуальны после недели ненависти к С++ на Хабрахабре.

Почему в конце декабря не работал Skype

Объяснение от разработчиков CIO update: Post-mortem on the Skype outage

Объяснение объяснения от разработчиков Understanding Today's Skype Outage: Explaining Supernodes

via highscalability.com

Ссылки по теме:
Архитектура Skype