_{Фото: ivan dupont}

Всем привет! Меня зовут Дмитрий Исайкин, и с недавних пор я занимаюсь мобильной разработкой. Почему с недавних? Еще три месяца назад я был руководителем группы C/C++-разработки Почты Mail.Ru. Но однажды я в очередной раз задумался о том, что мне всё меньше и меньше нравится то, чем я занимаюсь. Больше времени стали отнимать обязанности тимлида: мотивация, стимуляция, отчётность, административные заботы. И тогда я решил: пора что-то менять. Разместил резюме, сходил на несколько собеседований. Всё это время я размышлял о том, чего же я хочу. Мне предложили возглавить направление разработки в одной достаточно крупной фирме, и я практически согласился. Но, «переспав» с этим решением бессонную ночь, я понял, что такая работа будет мне не в радость. Ещё был вариант пойти старшим разработчиком в другую хорошую фирму. Но там пришлось бы заниматься примерно той же работой, что и в предыдущие годы.

Недавно на Хабре уже была статья о том, как «Mail.Ru для бизнеса» становится лучше благодаря вашим комментариям: мы рассказывали, как реализовывали ваши пожелания. Сегодня я хочу остановиться на одной из воплощенных хотелок — возможности настройки собственной DKIM-подписи. Для нас она была одним из приоритетов: настройка DKIM позволяет владельцам доменов верифицировать отправителя того или иного письма. В этом посте я расскажу о том, как мы внедряли эту возможность, и о том, как настроить DKIM-подпись для своего домена.

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

Кто-то оставляет проблему на «авось», кто-то вешает баннер на «пятисотку» и пытается зарабатывать на сбоях деньги. Кто-то пользуется стандартными решениями от поставщиков баз данных или сетевых устройств. А кто-то уходит в модные нынче «облака».



Ясно одно — по мере роста бизнеса обеспечение устойчивости к сбоям (даже не процедур восстановления после сбоев) становится всё более острой проблемой. От количества аварий в год начинает зависеть репутация компании, при больших временах простоя становится неудобно пользоваться сервисом, и т.д. Причин много.

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