Неполадки в работе сервисов 24-25 сентября

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


    Первый сбой


    Проблемы начались вечером в понедельник 24 сентября (даунтайм 22:00 — 23:10). Со стороны это выглядело как потеря связности с петербургским сегментом сети. Данный сбой повлек за собой проблемы во всех наших интернет-сервисах в Санкт-Петербурге; московский сегмент сети, а также локальные порты серверов продолжали работать. Также были недоступны DNS (ns1.selectel.org и ns2.selectel.org), которые находятся в Санкт-Петербурге, московский DNS (ns3.selectel.org) данный сбой не задел. Из-за отсутствия связности пропал доступ к сайту и панели управления, на телефонию пришлась основная нагрузка, в связи с чем многие клиенты могли не дождаться ответа.

    При анализе ситуации удалось сразу установить, что проблема вызвана некорректной работой коммутаторов уровня агрегации, которыми являются два Juniper EX4500, объединенные в единое виртуальное шасси. Визуально всё выглядело вполне работоспособно, но при подключении к консоли было обнаружено множество сообщений, которые, однако, не позволяли точно установить причину неполадок.

    Sep 24 22:02:02  chassism[903]: CM_TSUNAMI: i2c read on register (56) failed
    Sep 24 22:02:02  chassism[903]: cm_read_i2c errno:16, device:292
    

    По факту, перестали работать все оптические 10G Ethernet-порты на шасси коммутаторов уровня агрегации.

    Sep 24 22:01:49  chassisd[952]: CHASSISD_IFDEV_DETACH_PIC: ifdev_detach_pic(0/3)
    Sep 24 22:01:49  craftd[954]:  Minor alarm set, FPC 0 PEM 0 Removed
    Sep 24 22:01:49  craftd[954]:  Minor alarm set, FPC 0 PEM 1 Removed
    

    После перезагрузки всё заработало стабильно. Так как конфигурация сети до этого долгое время не менялась, и никаких работ до аварии не проводилось, то мы посчитали, что это разовая проблема. К сожалению, всего через 45 минут эти же коммутаторы снова перестали отвечать, и были еще раз перезагружены (23:55 — 00:05).

    Понижение приоритета коммутатора в виртуальном шасси


    Так как в обоих случаях первым выходил из строя один из двух коммутаторов в виртуальном шасси, и только следом за ним переставал работать второй, было сделано предположение, что проблема именно в нем. Виртуальное шасси было переконфигурировано таким образом, что основным стал второй коммутатор, а другой остался только в качестве резерва. В перерывах между выполнением операций коммутаторы еще раз были перезагружены (00:40 — 00:55)

    Разобрано виртуальное шасси, все линки перенесены на один коммутатор


    Спустя примерно час очередной сбой показал, что выполненных действий оказалось недостаточно. После освобождения и уплотнения части портовой емкости, нами было принято решение полностью отключить сбойное устройство от виртуального шасси и все линки перевести на “здоровый” коммутатор. Примерно к 4:30 ночи это было сделано (02:28 — 03:01, 03:51 — 04:30).

    Замена коммутатора на запасной


    Однако через час перестал работать и этот коммутатор. За время пока он еще работал из резерва был взят точно такой же полностью новый коммутатор, установлен и настроен. Весь трафик был переведен на него. Связность появилась — сеть заработала (05:30 — 06:05)

    Обновление JunOS


    Спустя 3 часа, около 9 утра, всё повторилось вновь. Мы решили установить другую версию операционной системы (JunOS) на коммутаторе. После обновления всё заработало (08:44 — 09:01)

    Обрыв волокон между дата-центрами


    Ближе к 12:00 были запущены все облачные сервера. Но в 12:45 произошло повреждение оптического сигнала в кабеле, который объединял сегменты сети в разных дата-центрах. К этому моменту из-за вывода из работы одного из двух опорных коммутаторов сеть работала только по одному основному маршруту, резервный был отключен. Это привело к потере связности в облаке между хост-машинами и СХД (сеть хранения данных), а также к недоступности серверов, размещенных в одном из петербургских дата-центров.

    После выезда аварийной бригады на место повреждения кабеля выяснилось, что кабель был обстрелян из пневматической винтовки хулиганами, которых удалось задержать и передать в полицию.
    image
    Нашим очевидным действием стало переключение на второй канал, не дожидаясь восстановления волокон по первому каналу. Это удалось сделать достаточно быстро, но только-только всё заработало, как снова зависание коммутатора. (12:45 — 13:05)

    Оптические SFP+ трансиверы


    В этот раз в новой версии JunOS в логах появились внятные сообщения и удалось найти жалобу на невозможность прочитать служебную информацию одного из SFP+ модулей,

    Sep 25 13:01:06  chassism[903]: CM_TSUNAMI [FPC:0 PIC:0 Port:18]: Failed to read SFP+ ID EEPROM
    Sep 25 13:01:06  chassism[903]: xcvr_cache_eeprom: xcvr_read_eeprom failed - link:18 pic_slot:0
    

    После извлечения данного модуля сеть восстановилась. Мы предположили, что проблема была в данном трансивере и реакции на него со стороны коммутатора, так как этот трансивер побывал в каждом из 3 коммутаторов, которые мы последовательно заменяли до этого.

    Однако спустя 3 часа ситуация снова повторилась. В этот раз в сообщениях не было указания на сбойный модуль, мы сразу решили заменить все трансверы на новые из резерва, но и это не помогло. Начали смотреть все трансиверы по очереди, вытаскивая по одному, был найден еще один проблемный трансивер уже из новой партии. Убедившись в том, что проблема с коммутаторами решена, мы провели перекроссировку внутрисетевых подключений для перехода на основную схему работы (16:07 — 16:31, 17:39 — 18:04, 18:22 — 18:27)

    Восстановление работы облачных серверов


    Поскольку масштаб проблемы изначально был не ясен, мы несколько раз пытались поднять облачные серверы. Машины, расположенные на новом хранилище (начало uuid’ов для SR: d7e… и e9f...) первые аварии пережили только как недоступность интернета. Облачные сервера на старых хранилищах, увы, получили I/O Error для дисков. При этом совсем старые виртуальные машины перешли в режим read only. Машины более нового поколения при этом имеют настройку error=panic в fstab, которая завершает машину в случае ошибки. После нескольких перезапусков, к сожалению, сложилась ситуация, когда подготовка хостов к запуску VM занимала непозволительно много времени (массовые IO error для LVM довольно неприятны; в некоторых случаях умирающая виртуальная машина превращается в зомби, а их отлов и завершение требует каждый раз ручной работы). Было принято решение перезагрузить хосты по питанию. Это вызвало ребут для виртуальных машин с новых хранилищ, чего мы очень не хотели делать, но позволило значительно (минимум в три раза) сократить время запуска всех остальных. Сами хранилища при этом стояли без сетевой активности и с нетронутыми данными.

    Предпринятые меры


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

    По итогам, было решено осуществить следующие мероприятия:
    1. Усиленная проверка оптических трансиверов и сетевого оборудования в тестовом окружении;
    2. Бронированный кевларовый оптоволоконный кабель в местах с риском повреждения в результате хулиганских действий;
    3. Ускорение завершения работ по модернизации инфраструктуры облачных серверов.


    Компенсации


    Вопрос, который интересует всех. В таблице ниже указаны размеры компенсаций по разным видам услуг в процентах от стоимости предоставляемой услуги за месяц, в соответствии с SLA.

    При том, что формально даунтайм сервисов был меньше указанного в таблице (связность иногда появлялась и исчезала), было принято решение округлить даунтайм в большую сторону.
    Услуга Время простоя Компенсация
    Виртуальный выделенный сервер 11 часов 30%
    Выделенный сервер/сервер произвольной конфигурации 11 часов 30%
    Размещение оборудования 11 часов 30%
    Хостинг CMS 11 часов 30%
    Облачные серверы 24 часа 50%
    Облачное хранилище 11 часов 50%


    Еще раз приносим извинения всем, кого задело это происшествие. Мы отлично понимаем, насколько негативно сказывается сетевая недоступность для клиентов, но как-то ускорить решение проблем не могли по причине того, что ситуация сложилась нестандартная. Мы предприняли все возможные действия для максимально быстрого устранения проблем, но к сожалению, установить точную проблему аналитическим путем не удавалось и пришлось искать её перебором всех возможных вариантов, что в свою очередь заняло много времени.
    Селектел 295,37
    ИТ-инфраструктура для бизнеса
    Поделиться публикацией
    Похожие публикации
    Комментарии 177
    • +51
      image
    • +10
      Коллеги, спасибо за самоотверженный труд и честный разбор произошедшего.
      • +10
        Минутку. По данным мониторинга (WEBO Pulsar) мой облачный сервер ушел в даун 24 числа в 22:08, а стабильно оклемался только 25 числа в 23:14, что составляет более 25 часов даунтайма, что по SLA ведет к 90% компенсации. Ваше «округление» срезает 40% компенсации.
        • +1
          В облаке вам предоставляется инфраструктура, именно ее работа и имеется ввиду. Если какие-то отдельные машины не сразу запустились — тут уже проблема на стороне клиента. А то так можно машину еще пару суток не запускать и просить за это компенсацию…
          • +8
            Машина не потребовала от меня никаких действий и запустилась автоматически, поэтому я никак не мог ни ускорить ее запуск, ни препятстовать ему.
          • 0
            Интересное замечание, но вот только о возможности запуска никто-никого не уведомил и инструкцию не прислал (а там многие машины требовалось пропинать перед запуском через консоль).

            А для того, чтобы понять процедуру (запуск с другого ядра, выполнения ряда комманд), приходилось писать в саппорт и ждать ответа.
            • +1
              IaaS. Предполагается, что вы знаете, как работать с серверами. Я целенаправленно веду к тому, чтобы облачный сервер был максимально похож на железный.
              • +1
                =) А еще предполагается, что я телепатически с ним связан и знаю когда именно надпись «подождите все машины запускаются» превратится в панель управления.
                • +1
                  А вот тут виноваты. В моём списке milestone нотификейшены (почта/джаббер, возможно SMS) о lifecycle виртуальных машин (и т.д.) есть, но на среднесрочную перспективу.
          • +8
            Напишите, пожалуйста, в поддержку через тикет-систему, возможно у вас компенсация будет выше. Ситуации могут быть разными, всё будет рассмотрено индивидуально. В статье указаны только те данные по компенсациям, которые относятся к большинству клиентов.
            • +3
              Написал, тикет #103614.
          • 0
            2е падение с компенсацией за кажется менее чем 2 месяца тестирования для своих нужд облачного сервера в #selectel. Подумал ещё и решил, что рановато мне пока в облака, отправился на VDS.

            Но спасибо за описание, думаю светлое future ещё предстоит :)
            • +2
              А как VDS может спасти от подобной проблемы с сетью?
              • 0
                Никак само собой, просто наблюдения за clodo и selectel как бы намекают, что пока не очень хорошо отлажены процессы и невысока надежность. В данном случае проблемы были ниже, но чаще софт и организация системы видимо приводят к нестабильности.

                С VDS процессы и системы просто лучше отработаны, они как дебиан на фоне других линуксов в сравнении с облаками :)
                • +3
                  Если честно, не вижу разницы кроме той, что в большинстве реализаций VDS мне не гарантированы те ресурсы которые я потребляю или же у меня их переизбыток за который я плачу. У парней из Сlodo и Selectel получилось сделать тот же самый VDS, только более честный. Учитывая тот факт, что Selectel вот-вот закончит свою модернизацию, то надежность должна вырасти. Москва ведь тоже не сразу строилась. Я видел очень много разношерстного железа, на которых крутятся VDS-ы у зарекомендоваших себя хостерах и сравниваю с тем, на чем крутятся облака у Selectel и Clodo. У первых встречаются даже Desktop решения с древнейшими цисками. Предпочтение отдаю тому, у которого есть собственные ДЦ т.к. чувствую, что прогресс сдесь будет развиваться быстрее.
                  • +1
                    *здесь
                    • +3
                      Поддерживаю. В Selectel больше уверенности чем в clodo. Да и производительность (виртуальная, если можно так выразиться) у них выше. Тестировал на hlds-ах Counter-Strike 1.6, fps-а (игрового сервера) на виртуалках Selectel-а ощутимо больше. На clodo и вовсе фризы бывают по паре секунд. Единственное что очень досадно — нет облака Selectel в Москве. Я понимаю, что для сайтиков это совсем не критично, но когда каждые 5мс сетевой задержки конкурентное преимущество… Это грустно. Очень жду облако в московских ДЦ, но ни кто внятной информации об этом не дает. Оно и понятно, не может же быть двух amaramo, или не будет же кататься amarao из Москвы в Питер :) И да, в облаке Selectel можно запуститься на своем кастомном ядре, чего невозможно сделать в clodo. У меня конечно еще не получилось, то ТП утверждает что да, таки можно :) Молодцы!
                      • +1
                        Для развёртывания облака физическое присутствие не нужно.

                        Мы сначала закончим все переходные процессы тут, и только потом в МСК.
                        • 0
                          Т.е. в планах железно есть и это лишь вопрос времени? Если да, то назовите хотя бы приблизительные сроки, хочу жить с надеждой :)
                          • 0
                            Сроков нет, надежда есть =)
                            • 0
                              Тут скорее всего решающим фактором станет целесообразность вложения средств в модернизацию инфраструктуры московского дата-центра, закупки оборудования для резервирования. Также необходимость выделить нужные емкости оптических волокон. Может даже построить резервную оптическую линию. Подведение необходимого канала связи, закупка трафика у вышестоящего оператора и т.д. Все это немалые вложения, которые должны окупиться хотя бы за 3 года. Не думаю, что открытие облака в Москве приведет массу новых клиентов. Скорее всего это будет расширение услуги для уже существующих, вряд ли на первом этапе можно ожидать резкого повышения оборота. Именно поэтому, может остаться только надежда.
                • +5
                  Хорошо, что рассказали.
                  • 0
                    Жаль, из пяти облачных систем (Почти все на разных акках и созданы в разное время) одна сдохла напроч, на паре пришлось делать фсчк, на одной обошлось фсчк через ресью ядро.

                    Все мои клиенты, которых я давно уболтал перехать в облако, от вас к сожалению уйдут. С надежностью у вас какой-то ад.

                    Страно что проблемы с коммутатором и проводом привели к насмерть убитым файловым системам почти во всех случаях.
                    • +1
                      Связь коммутаторов и СХД описана в статье, прочитайте внимательнее.
                      • 0
                        Мне это мракобесье будет тяжело обьяснить своим питерским клиенам.
                        Все было бы ничего (Даунтайм в пол дня можно забыть, тем более уже не первый раз такое) если бы на одном сервере не гакнулась файловая система с потерей почти всех данных.
                        • 0
                          К сожалению, от потери данных не застрахован никто, резервное копирование стоит выполнять даже на самых надежных серверах.
                          • 0
                            Да вы правы, но в таких случаях всегда ругают почему-то хостера.
                            Может быть в вашем случае будут ругать парня с пневматикой :)
                            • +1
                              Лучше поругать себя и для бизнес-критикал систем настраивать резервирование целых серверов с распределением по нескольким ДЦ.
                              • +10
                                Любое повышение надежности инфраструктуры ведет за собой повышение цен на ее ресурсы. Уверен, что если в Селектел придет человек и скажет, что мне нужна облачная инфраструктура с очень серьезным резервированием всего и распределением по дата-центрам, то ценник за ресурсы будет совсем иной. А когда есть люди, которые платят 200 рублей в месяц за облачной VDS и при его падении поднимают ор в твитере в стиле «Я теряю миллионы» не позаботившись при этом о его бэкапе, то вряд ли им это будет вообще интересно. Больше денег они все равно не заплатят.
                                • +2
                                  Всё верно, приятно знать, что есть люди, понимающие это.
                                  • +1
                                    Мы учли ошибки, сделанные ранее. Новая СХД, с которой мы возились с июня, и в которой аварии на любом компоненте хранилища не приводят ни к чему, кроме 10-20с паузы в обслуживании (лагу) — и это в худшем случае. На цене iops/места оно не скажется (по крайней мере в течение ближайшего полугода — дальше заглядывать не могу).
                                    • 0
                                      Приятно слышать, мне очень нравится ваша платформа. И очень не нравится проблемы с фс клиентов после любых проблем на вашей стороне.

                                      Новая СХД для старых облачных систем работает тоже, или надо пересоздавать сервер чтобы он получил новую СХД?
                                      • +1
                                        1) Новые машины идут туда.
                                        2) Все существующие (в обоих пулах) будут перенесены.
                                        3) При переносе будет даунтайм на 1-40 минут в зависимости от размера диска.
                                        4) Предупреждаем заранее.
                                        5) Перенос партиями с 1 до 9 ночью.
                                        6) Сами выключаем (gracefully), после переноса включаем.
                                        • 0
                                          Снапшоты теперь тоже у всех будут работать?
                                          Отлично, спасибо!

                      • +8
                        Особенно повеселили ребята с пневматами, такой неожиданный сюжетный поворот.
                        • +3
                          Это разгневанные клиенты. :)
                          Хотя больше похоже на конкурентов.
                          • +1
                            очень похоже на конкурентов, которые захотели чтобы «полежало подольше»
                            • 0
                              Скорее хотели пострелять по птичкам сидевшим на кабеле.
                              • 0
                                В нормальном режиме это два совершенно независимые линка, находящиеся на расстоянии несколько километров (десятков километров?) друг от друга.
                          • +9
                            Админы поседели уже к девяти утра первого дня.
                            • 0
                              Да, вот интересно, их кормили эти сутки чем-нибудь? А поспать часик давали? :)
                              • 0
                                Поспать вряд-ли давали, разве что те моменты когда считали что проблема решена. :)
                                • +4
                                  У нас были работы в понедельник в 7 часов. Я уехал домой и лёг спать в 21:00, в полночь меня разбудил инженер саппорта. Я поехал в Селектел (т.к. наша админка не работала в этот момент, а по Питеру в это время до Селектела ~12 минут езды), после сидел, готовился, писал простыни в notification, ждал, даже помогал вынимать 4200 из стойки.
                              • 0
                                хм… зачем-то мне включили вторую машину, которая была уже год как выключена и там ей и место.
                                второй сервер, включен, но не пингуется.

                                Точно все починили как следует?
                                • +1
                                  Мои машины со вчерашнего вечера нормально работают.
                                  Та, что включена но не пингуется — открывай консоль, наверняка диск просит fsck запустить.
                                  • 0
                                    да нет, ничего не просит.

                                    Внутри машины тоже глухо как в танке

                                    root@vm:~# ping ya.ru
                                    ping: unknown host ya.ru
                                    root@vm:~# ping 8.8.8.8
                                    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

                                    ^C
                                    — 8.8.8.8 ping statistics —
                                    78 packets transmitted, 0 received, 100% packet loss, time 76999ms

                                    *это из консоли в панели управления
                                    • +1
                                      Лучше продолжить в тикете.
                                      • 0
                                        ну и в тикете я тоже написать не забыл)
                                  • 0
                                    Из-за массовости процесса алгоритм обнаружения «должна быть включена» довольно хитрый. Возможно, запустили ошибочно.

                                    Для «не пингуется» — 99.9%, что fsck хочет проверку. Для машин эта авария была эквивалентна обыкновенному отключению по питанию.
                                    • +3
                                      Не в первый раз замечаю, что у вас для хостера очень символичный аватар…
                                      • 0
                                        Дуров, верни стену amarao, верни мне мой кусок облака!
                                        Даже на тикеты уже ничего вразумительного в ответ я не могу получить.
                                    • +5
                                      Очень радуют такие подробные описания проблем. Действительно ситуация нештатная, но как бы там нибыло даунтайм есть даунтайм. Лично у меня сервер на linode уже поднят. Часть проектов переношу туда, а часть оставляю тут, дабы всегда иметь возможность быстро перебросить сайты с одного сервера на другой.

                                      А вообще, вам неплохо было бы нанять человека для анализа и контроля рисков. Пусть этот человек анализирует где «дракоша» попробует совершить очередную попытку суицида. Только не нужно воспринимать эту рекомендацию, как «возьмите козла отпущения».

                                      Искренне желаю вам и вашим клиентам вечного аптайма;-)
                                      • +5
                                        Какова, интересно, вероятность того, что одновременно с обнаружением дефектов в целой партии оборудования хулиганы подстрелят именно тот кабель? Майор Паранойя чует заговор.

                                        Кстати, облачное хранилище перестало быть доступным по https. Возможно, это произошло и до этой аварии, но сейчас отвечает 303 с редиректом на http. Это довольно грустно. Зачем так?
                                        • 0
                                          Разве что конкуренты подлили маслице в огонек. Маловероятно, но может быть. Как при этом они могли быть задержаны, это ХЗ.
                                          • 0
                                            Я к тому, что они знали что шли не с пивком птичек пострелять, а на дело. Значит должны были тикать.
                                        • +5
                                          Ребята, я уже третий раз думаю от вас уйти. И каждый раз даю вам еще один шанс. Пожалуйста — не подведите.
                                          • 0
                                            До завершения работ не могу обещать. После — аварий СХД не будет.
                                          • +10
                                            Предлагаю завести хаб «Селектел упал», чтобы от него отписаться
                                            • +3
                                              Попробую напрячься и организовать. Не хаб, а отсутствие таких проблем. С этой аварией нас поймали на самом сложном моменте. С 27ого (с этой ночи) начинаются массовые переносы клиентов на новые сторы, там никаких багов mpt2sas, ixgbe, aacraid, linux-raid и т.д. не будет.
                                              • +1
                                                Звучит слишком самоуверенно, для системы состоящей из десятков сложных сервисов работающих вместе. Я вот никогда не даю таких гарантий даже для единичных сервисов — досконально проверить все просто невозможно.
                                                • 0
                                                  а процесс переноса будет прозрачный, или будут сервера отключать?
                                                  • 0
                                                    Будут отключать, о чем amarao писал выше. Xen и сопутствующие либо еще не узнали о svmotion, либо не смогли сделать аналог.
                                                    • 0
                                                      Там много сложнее. Если бы речь шла про перенос между sr'ами — это одно. У нас же машина переносится из старой инфраструктуры в новую.
                                                    • 0
                                                      Так как оно между друг другом никак не совместимо, то перенос будет делаться банальным sparse_dd, который, увы, требует выключения машины.
                                                      • 0
                                                        ndmp copy?
                                                        • 0
                                                          У XCP свой механизм копирования данных между SR'ами с правильным учётом дырок внутри VHD.
                                                          • 0
                                                            можно кстати использовать gzip ugzip через пайп, иногда эффективнее sparse_dd
                                                            • 0
                                                              Лучше я лишний раз это всё теребить не буду. Кроме того, gzip не оставит дырок в новом файле, а это плохо для (когда-нибудь починенных) снапшотов.

                                                              С учётом, что я двигаю кучу дисков (прям сейчас, кстати) — это не есть быть гут.
                                                              • 0
                                                                В файлах да, я же использовал это на блочных устройствах, там gzip соответственно записывал нужное количество нулей на выходном устройстве.
                                                                • 0
                                                                  Тыг не имеет смысла. В нижележащем (под блочным устройством) уровне всё равно VHD, а ему что нули, что данные — всё запись.

                                                                  Дырки можно только с помощью sparse_dd сохранить.
                                                                  • 0
                                                                    Да, я понимаю, просто как вариант предложил. Особенно актуально если узким местом является сеть, то gzip неплохо уменьшает объем передаваемых данных. Как вариант sparse_dd + gzip =)
                                                • 0
                                                  За описание спасибо.
                                                  Увы 3й раз за 2 месяца это слишком, переезжаю на AWS, у них замечательный бесплатный micro instance для небольших проектов и цены на spot instances очень радуют для проектов поболее…
                                                  • +3
                                                    замечательный бесплатный micro instance

                                                    Для вас он может оказаться очень не бесплатным, когда вы вдруг внезапно превысите границы бесплатных лимитов.
                                                    • 0
                                                      Для моих потребностей в ближайшее время бесплатных лимитов более чем достаточно. Я изучил этот вопрос, прежде чем переносить туда сервер.
                                                  • +1
                                                    > так как этот трансивер побывал в каждом из 3 коммутаторов
                                                    Не понял этот момент, как так?
                                                    На резервном коммутаторе не поставили необходимое число модулей и перевтыкали из основного?
                                                    • +1
                                                      Меняли коммутаторы, трансивер «переезжал» из коммутатора в коммутатор вместе с линком, который он обслуживал.
                                                    • +1
                                                      > Ускорение завершения работ по модернизации инфраструктуры облачных серверов.

                                                      О нет, только не это! Ну вы там не торопитесь особо, лучше уж наоборот не спешите, чем ускоряйте. Спешка она порой известно к чему приводит.

                                                      P.S.: обожаю такие статьи — что только на свете не бывает :)
                                                      • 0
                                                        Ускорение = перенос дисков в более принудительном порядке.

                                                        На ночь 27 (сегодня), 28, 29 уже всё расписано. Остальным придут уведомления за три дня до начала переноса.

                                                        Специально что-то форсироваться не будет — новая СХД в продакте с начала сентября, новые диски создаются там, на них уже больше 1000 дисков создано.

                                                        Единственный элемент форсирования — я хотел дать возможность людям выбрать самим диапазон времени переноски — но на кодирование и отладку этого нет времени, так что всех с 1 до 9 каждую ночь будем двигать.

                                                        ЗЫ Если кто наблюдал за бесконечными плашками вида «панель управления будет отключена» и т.д. — это как раз эти самые работы. Основная часть уже сделана — осталось только перенести клиентов.
                                                        • 0
                                                          Т.е. если для меня был тикет о работах «в понедельник, 24.09.2012, с 7 до 13 часов» и панель действительно на какое-то время была отключена, то это значит, что моё уже перенесли? Или вы её всем отключаете и не факт что работы затронули непосредственно мои виртуалки?
                                                          • 0
                                                            Отключение панельки — это «наши» работы, они не затрагивали клиентов.

                                                            Перенос — это когда машину выключают на некоторое время (за 3 дня до приходит тикет). Признак нового хранилища — в дисках SR uuid — d7e… или e9f… в зависимости от пула.
                                                      • 0
                                                        А компенсация будет начислена автоматически?
                                                        • 0
                                                          Задал этот вопрос через тикет-систему, сказали что да — автоматически в конце месяца.
                                                          • 0
                                                            Автоматически, но могут быть накладки. Компьютеру очень трудно объяснить, что запущенная машина — это сломанная машина, а машина, которая просто ребутнулась где-то сразу после аварии — рабочая.

                                                            Если к 10ому не будет компенсации за включенные машины, которые задело аварией — пишите тикет о том, что нет компенсации, их я вручную разбираю.
                                                            • +1
                                                              Могу ошибаться, но мне кажется что не приходит никакого извещения о компенсации.
                                                              Есть ли способ о ней узнать не отслеживая постоянно состояние счета?
                                                        • +6
                                                          Это такой высокобюджетный хоррор для айтишников, можно в кинотеатрах экранизацию показывать. А поворот со стрельбой вообще ад, на этом моменте сами зрители начинают немного подвисать.
                                                          • +1
                                                            Трансиверы «родные», или китайские аналоги?
                                                            • +1
                                                              Наверное «родные» — китайские
                                                              • +1
                                                                Уточню. Судя по:
                                                                1. приведенному вами сообщению в логах («Failed to read SFP+ ID EEPROM»);
                                                                2. по описанию подбора «рабочих» SFP;
                                                                3. по отсутствию упоминания общения с JTAC (за 24 часа можно было создать хотя бы 1 кейс)
                                                                проблема была в некачественных аналогах трансиверов.
                                                                • +3
                                                                  Трансиверы не родные, но данный производитель использовался уже несколько лет.
                                                                  С JTAC мы связались и получили две ответные реакции:
                                                                  1. Трансивер не наш — идите лесом.
                                                                  2. Реакция на сбойный трансивер (даже не их производства) не типична — создали кейс.
                                                                  • +3
                                                                    Большое спасибо за прямой ответ!
                                                                    Был подобный опыт с той же проблемой на неродных трансиверах: долго работало, внезапно перестало с той же ошибкой. Кейс закончился ничем.

                                                                    Может, вам, кроме хронологии и защиты amarao все же попробовать в следующий раз прибегнуть к коллективному разуму? Спотыкались, как видите, не одни вы. Это просто предложение к размышлению.
                                                                    • 0
                                                                      Спасибо за понимание, но боюсь что во время даунтайма коллективный разум не столь хладнокровен в суждениях и точно не благоразумен на подсказки…
                                                                    • +2
                                                                      А на чём ещё вы сэкономили?
                                                                      • +14
                                                                        На адвокатах, которые могли бы удачно объяснить произошедшее непреодолимой силой и отвертеть компанию от выплаты компенсаций.
                                                                • 0
                                                                  Касательно ошибок «CM_TSUNAMI: i2c read on register (56) failed», а у вас есть подписка на их саппорт?
                                                                  • 0
                                                                    А компенсировать недоступность живых московских серверов из-за не отвечавших NS будете? :)
                                                                    • 0
                                                                      Недавно (до данной аварии) была рассылка с просьбой всем клиентам прописать все три наших NS сервера в СПб и МСК, если вам такой тикет не пришел, напишите, пожалуйста в саппорт.
                                                                      • 0
                                                                        Написал, с двух аккаунтов. Похоже, в обоих не было этого тикета.

                                                                        Тикеты #106590 и #106589.
                                                                        • 0
                                                                          Ну, собственно, чтд. Рассылка была, но она была не об ns-серверах, а о кэширующих DNS-серверах:
                                                                          В ночь с 28 на 29 августа произошел сбой на одном из наших кэширующих DNS серверов (ip 188.93.16.19) повлекший за собой проблемы со связью на клиентских серверах. Сбой полностью устранен и предприняты меры для предотвращения повторных сбоев.

                                                                          Для избежания подобных проблем просим Вас проверить сетевые настройки на Ваших серверах и указать в качестве DNS серверов все наши кэширующие серверы:
                                                                          188.93.16.19
                                                                          188.93.17.19
                                                                          109.234.159.91
                                                                          Также Вы можете использовать любые другие доступные DNS серверы.

                                                                          Приносим извинения за доставленные неудобства.
                                                                      • 0
                                                                        Недоступность NS — это вообще самое страшное что может быть имхо, выучил урок после ддоса Zerigo.

                                                                        У вас всего 3 сервера, для компании Вашего масштаба маловато, на мой взгляд.
                                                                        • +4
                                                                          Хм… всего 3? тогда у гугла всего 4 =(
                                                                          • +3
                                                                            Вместо язвительного остроумия положено говорить примерно следующее:

                                                                            у нас три доменных имени для NS серверов, каждое из которых через раундробин отдает несколько юникастовых айпишников (причем сами записи хостятся не на этих серверах), суммарно NS серверов 84 штуки, каждый минимум на гигабитном канале, все разнесены географически на 12 независимых точек.
                                                                          • 0
                                                                            Такие проблемы решаются, если slave NS держать у другой компании, и в другом месте.
                                                                            • 0
                                                                              Это правильно, но при условии, что примари поддерживает AXFR. Не знаю, поддерживается ли оно у селектела.
                                                                          • +2
                                                                            Знаете, я уже начинаю думать, что вы сами свои кабели обстреливаете, чтобы как-то оправдывать свой даун-тайм.
                                                                            Но вот люблю я вас, с другими ещё хуже всё.
                                                                            • 0
                                                                              >После выезда аварийной бригады на место повреждения кабеля выяснилось, что кабель был обстрелян из пневматической >винтовки хулиганами, которых удалось задержать и передать в полицию.
                                                                              Хулиганы всё это время ожидали аварийной бригады?
                                                                              • +2
                                                                                Вы не поверите, но они и бригаду обстреляли, но, к счастью, попали только в рядом стоящий столб…
                                                                                • +1
                                                                                  В кабель попали, а в бригаду нет?…
                                                                                  • +2
                                                                                    Кабель не уворачивался, и не бежал на врага с монтировкой :)
                                                                                    • 0
                                                                                      Из пневматики довольно проблематично вообще куда-либо попасть. Так что тут чудеса какие-то чудесатые творятся ))
                                                                                  • 0
                                                                                    Вы это на полном серьезе?
                                                                              • 0
                                                                                Может быть есть какая-нибудь техническая возможность разделить #spb и #msk, по крайней мере для дедиков? Тогда в случае таких проблем, вони будет минимум меньше на одного клиента.
                                                                                • 0
                                                                                  #spb и #msk разделены, каждый сегмент имеет свои независимые аплинки и является полностью автономным сегментом, но клиенты, которые обращались к московским серверам из питера пускались через наш линк спб-мск (поскольку иногда граничный маршрутизатор успевал прокидывать анонсы операторам в спб), а он в свою очередь терминировался на всё том же злополучном опорном коммутаторе…
                                                                                • –10
                                                                                  Вымытый обстрелянный кабель с пулькой рядом — конечно верю.
                                                                                  • +6
                                                                                    На самом деле это наша попытка переложить на посторонних ответственность за 4ый из 7 случай падения сети. Разумеется, если нам удастся убедить общественность, что именно 4ый раз был результатом чьего-то хулиганства, то мы сможем заявить, что даунтайма не было и нам не надо будет признавать, что первые три до и все последующие — наша вина.

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

                                                                                    Так?
                                                                                    • –7
                                                                                      Да не важно, я уже не ваш клиент.

                                                                                      Сначала я вам радовался, потом вы меня огорчали, а потом и вовсе уничтожили мой HDD.

                                                                                      Ну а потом была мега-компенсация, 3.26 руб, уже и не помню, за какой именно простой.

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

                                                                                      Извините за язвительный комментарий про кабель, просто не смог пройти мимо этой фотографии. Очень жаль, что вы так резко упали.
                                                                                      • 0
                                                                                        Спасибо за объективные комментарии. Компенсацию за мелкий даунтайм на несколько минут вы упомянули, а весьма значительную компенсацию за потерю данных — нет.
                                                                                        • +1
                                                                                          Весьма значительную — это сколько?

                                                                                          Напомните, пожалуйста.
                                                                                          • 0
                                                                                            После чего на хабре появится комментарий о том, что мы делаем дисклоуз финансовых данных клиента. И мы будем долго и безутешно объяснять, как подумали, что некий ник на хабре равен нашему клиенту.

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

                                                                                              Если не изменяет память, сумма там была до 300 рублей.

                                                                                              Так?
                                                                                              • +7
                                                                                                Извините, мы раскрываем данные клиента только с их согласия. Любые методы социальной инженерии в данном случае не прокатят, единственным методом является прямое разрешение через установленные договором методы взаимодействия, которые позволяют убедиться в том, что говорящий — и есть клиент.
                                                                                                • –2
                                                                                                  Молодцы.

                                                                                                  И все думают, будто «значительная компенсация» была. Снимаю шляпу.
                                                                                          • –2
                                                                                            Раз уж пошел такой разговор — я напоню еще, что вашу компенсацию можно потратить только на ваши же услуги.

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

                                                                                            Здесь остальной текст.
                                                                                            • 0
                                                                                              Будто где-то это не так.
                                                                                              • –4
                                                                                                Не знаю, у Linode простоев пока просто нет.
                                                                                                • +6
                                                                                                  Когда будут — вы то же вывести компенсацию не сможете. :)
                                                                                    • +2
                                                                                      Ну не верю я в такие совпадения. Обнаружил, что одна из машинок недоступна еще около 15 часов по Москве 24го. Ничем её доступность не мониторю, так что конкретнее сказать не могу. Как позже, по логам, выяснилось — машинка работала, была недоступна сеть(!!!). Времени разбираться не было. До вечера так и не поднялась, около 19 отписал тикет(#103528). Примерно через час пришел ответ, что поднимут после технических работ с сетевым оборудованием(!!!) ночью. Тут же написано, что проблемы начались вечером, с падения в 22. «Стрелки» затронули, опять же, как раз именно сеть. Странно это все…
                                                                                      По поводу компенсаций — это все, конечно, замечательно, но… В этом году мне пришла компенсация только за августовское падение и только за одну машинку (лежала не только она), за другие падения — ничего.
                                                                                      В общем, у меня 31 час даунтайма — сурово. Благо тестовые машинки и не особо важные сайты.
                                                                                      • 0
                                                                                        Извините, вы прочитали написанную хронологию аварии? Она началась ночью 23его и длилась 24ого. Если у вас «всего лишь не было интернета» — значит машина была на новом хранилище.
                                                                                        • 0
                                                                                          Про 23е вообще в посте не вижу. А не 24-25го?) Машинка, если не ошибаюсь, со старого пула.
                                                                                          • 0
                                                                                            Моя ошибка. С остальным, я думаю, лучше в тикет.

                                                                                            Если где-то не выплачена компенсация — укажите для какой машины и когда примерно была проблема, я перепроверю, правильно ли роботы отработали.
                                                                                            • 0
                                                                                              Остальное с 24го в тикете, тут почти ничего нового:) Компенсации обычно копеечные, писать было даже лень. Хотя, пожалуй, на счет августовского и правда отпишу.
                                                                                        • 0
                                                                                          Извините. У меня из-за работ собственная хронология съехала, выше комментарий неверный.
                                                                                      • 0
                                                                                        Парни, через эти проблемы пройдет любой хостер, который захочет выйти на этот рынок.

                                                                                        Потом у вас начнутся такие же проблемы со связностью отдельных ДЦ и availability зон. Но это естественно. Решайте проблемы и развивайтесь!
                                                                                        • 0
                                                                                          >Sep 24 22:02:02 chassism[903]: CM_TSUNAMI: i2c read on register (56) failed

                                                                                          Ну сразу же понятно, что проблема аппаратная.
                                                                                          • +1
                                                                                            все эти пертурбации навели меня на мысль что неплохо бы написать howto о том что делать во время и после аварии. ну там fsck, lvm как руками поднимать и проч.

                                                                                            оно конечно гуглится за пять минут, а ежели часто делаешь так и вообще в подкорку залезает, но как раз дело в том что слава богу нечасто надо это делать, а минуты эти — критичны.
                                                                                          • 0
                                                                                            > По итогам, было решено осуществить следующие мероприятия:
                                                                                            > 1. Усиленная проверка оптических трансиверов и сетевого оборудования в тестовом окружении;

                                                                                            А вариант поставить «родные» трансиверы на критических узлах не прошел?
                                                                                            • +2
                                                                                              Наша задача — полностью исключить даунтаймы в будущем, а не написать в случае возникновения проблем в следующий раз «мы все делали правильно, во всем виноват Juniper/Cisco/Extreme или еще кто-то» — от этого никому легче не будет. Все-таки мы исходим из того, что надо обеспечивать надежность сети правильной архитектурой с внутренним резервированием, а не полагаться на отказоустойчивость отдельных компонентов (любое, даже самое надежное оборудование, может выйти из строя).
                                                                                              • +1
                                                                                                С учетом того что они делаются почти на одном заводе?)
                                                                                                • +1
                                                                                                  Такое уместно только в одном случае: выполнить обязательные условия вендора чтобы исключить возможность отказа в поддержке. «Страховой случай» :)
                                                                                                  • 0
                                                                                                    Как уже было сказано, техпод вендора далеко не всегда полезен в критичных и сложных случаях, когда он больше всего нужен. А чинить банальные неполадки мы и сами неплохо умеем.
                                                                                                    • 0
                                                                                                      Ну ты же понял о чем я? Чтобы не посылали а начали быстро решать проблему с высшим приоритетом, конечно для этого нужно уметь эскалировать.
                                                                                              • +2
                                                                                                В этот раз в новой версии JunOS в логах появились внятные сообщения и удалось найти жалобу на невозможность прочитать служебную информацию одного из SFP+ модулей,

                                                                                                Буквально весной, когда проходил обучение по джуносу инструктор несколько раз делал акцент на том, что с каждой новой версией джуноса служебные сообщения становятся все более читаемыми для простых смертных, ну и еще как бонус — загружается устройство с каждой новой версией всегда немного быстрее чем с предыдущей. Именно поэтому вопреки убеждению большинства «пока работает — не трогай» нам дали рекомендацию всегда обновляться на свежие версии JunOS. Не на последнюю, а на предпоследнюю версию (к примеру сейчас доступен 12.2R, значит девайсы надо держать на 12.1R), т.к. в совсем свежих могут быть неизвестные баги.

                                                                                                Ну и вопрос к представителям Селектела, меня этот момент очень смутил:
                                                                                                Неужели оборудование, которое установлено в критичных узлах не имеет контрактов на поддержку?
                                                                                                Проблема с которой вы столкнулись явно относиться к наивысшему приоритету Priority 1, Critical. Гарантированное время реакции — 1 час. Проблема не слишком сложная, так что ее бы решили очень быстро. Я уже не говорю о том, что в случае, если бы в течении 2-х часов не было решения, можно было бы эскалировать проблему руководителю службы технической поддержки, через 4 часа — вице-президенту, отвечающему за техническую поддержку и вице-президенту отвечающему за разработку.
                                                                                                • 0
                                                                                                  JTAC имел право их послать из-за использования неоригинальных трансиверов.
                                                                                                  • +1
                                                                                                    Я видимо где-то не дочитал об этом… Тогда мне становится еще больше не понятна политика Селектела — в mission critical узлах использовать оборудование, которое официально не совместимо %)
                                                                                                    • +2
                                                                                                      «официально не совместимо» и «не совместимо официально» разные вещи ;)
                                                                                                      Трансиверов-то по сути не так и мало нужно, и переплачивать 300% за оригинал не всегда кажется выгодным.
                                                                                                      Особенно циско этим грешит, продают, скажем, за 200 баксов, а аналог, так сказать cisco-compatible, стоит 50.
                                                                                                      • 0
                                                                                                        Вам важнее экономия лишних 100-200 тыщ $$ или стабильность работы инфраструктуры и лояльность клиентов как текущих, так и будущих?
                                                                                                        • +3
                                                                                                          Хреновые трансиверы бывают у всех. Бывает и оригинальные Cisco страдают фигней, перегреваются и припаиваются к слоту, а «левые» OptiCin работают идеально.
                                                                                                          • 0
                                                                                                            Ниже mark_ablov во втором своем предложении дал четкий ответ. Сапорту уже не отвертеться
                                                                                                          • 0
                                                                                                            Гарантий того что железка от вендора стабильна — нет.
                                                                                                            Разве что саппорт пободрее.
                                                                                                            Насколько я понял, не была обеспечено полноценное дублирование, а приходилось линки перевтыкать в резвервный коммутатор, что имхо не является дублированием.
                                                                                                            • +2
                                                                                                              Да нет… Судя по посту — там сразу был Virtual Chassis, только его развалили, предполагая что дело в одном из коммутаторов. Потом уже началась паника и дерганье всего подряд лишь бы по-быстрее «запуститься».
                                                                                                    • +5
                                                                                                      Конечно, были обращения и в JTAC и общение с инженерами российского Juniper. Но проблема в том, что и те и другие могут что-то сказать и как-то помочь только на основании информации, предоставленной с нашей стороны. В описанных случаях в логах до обновления JunOS никакой конкретики не было. Как только в логах появилось сообщение о неисправности SFP+, то нам и самим стало ясно что нужно менять трансиверы — спустя 15 минут тоже самое подтвердили инженеры Juniper.

                                                                                                      Что касается сервисных контрактов в целом, то опыт их использования скорее негативный (в том числе в одном партнерском проекте в котором на порядок больше оборудования по сравнению с сетью дата-центров Селектела). Одно время мы приобретали премиум контракты с 4-х часовой заменой оборудования в случае его неисправности вообще для всего сетевого оборудования, но по факту при всех неполадках поддержка оперативно помочь не могла, быстрее разбирались сами, и ни одна «4-х часовая» замена не прошла быстрее, чем за 12 часов (среднее время — 16 часов). Сеть смешанная Cisco/Juniper. Не думаю, что у других вендоров с этим как-то сильно лучше.
                                                                                                      • 0
                                                                                                        JTAC-y понадобилось ~10 часов (с момента первого сбоя в 22:00 до момента пока вы обновили JunOS — 8:44 следующего дня) что бы дать Вам рекомендацию обновить джунос? Они не смогли идентифицировать что проблема аппаратная и не зависит от конкретной железки пока вы не обновили джунос и сами не увидели явное сообщение, гласящее о том что проблема с SFP+ трансивером? Была ли эскалация на высшие уровни, раз обыкновенные инженеры не могли решить проблему?

                                                                                                        Я это все к чему спрашиваю: мы планируем относительно небольшой проект на оборудовании от Juniper и хотелось бы знать насколько качество JTAC соответствует заявленному.

                                                                                                        ЗЫ а можно версии JunOS (которая стояла изначально и на какую обновились)?
                                                                                                        • +2
                                                                                                          Была 11.2R1.2 — стала 11.4R2.14
                                                                                                          Мы всегда ставим рекомендованые JTAC версии.

                                                                                                          Качество JTAC боюсь, что определиться может только для определенных ISSUE.
                                                                                                          В нашем случае issue всё еще в обработке, т.к. один трансивер не должен утаскивать все возможные FPC свитчей, а только класть один проблемный порт…
                                                                                                    • +1
                                                                                                      Так а что мешает текущим трансиверам опять слететь? Этот вопрос как-то будет решаться, или мы просто ждем следуюего факапа с ними и быстро устраним неисправный?
                                                                                                      • –1
                                                                                                        А тем временем у меня пропала вся статистика использования дисков по серверу в облаке. Вобщем-то я уже съехал и по большому счету мне все равно, наводит на размышления…
                                                                                                        • +2
                                                                                                          Статистика не «съезжает», диски были перенесены на новое хранилище, у них новый uuid. Данные по старому uuid'у всё ещё есть, их не показывает панель. issue есть, так что в ближайшее время графики будут просто «суммироваться» о всем uuid'ам, связанным с машиной (т.е. будут показываться в прошлое вне зависимости от перерыва).
                                                                                                        • 0
                                                                                                          прям шедевр
                                                                                                          • 0
                                                                                                            Но! Пожалуйста! Сделайте наконец возможность менять пароль от аккаунта через HTTPS, а не методом пересылки его открытым текстом по почте.

                                                                                                            Даже обидно, что пароль какого-нибудь субпользователя на хранилище можно сгенерировать и забрать по HTTPS, а главный пароль ОТ ВСЕГО просто так ходит по интернетам :(
                                                                                                            • +2
                                                                                                              Если у вас правильно настроен сервер, то почта будет ходить по шифрованному соединению между серверами.

                                                                                                              А насчёт пользовательских паролей… Мы один раз разрешали пользователям давать пароль для машины при создании. Пришлось отказаться — слишком высокий процент квертизма там был.
                                                                                                              • 0
                                                                                                                Речь скорее про изменение пароля через вебформу — отправка данных вебформы идет без шифрования.
                                                                                                                • +2
                                                                                                                  Подождите, какая «отправка пароля»? Куда? На support.selectel.ru нельзя поменять пароль. На облако — только посмотреть дефолтный пароль рута при установке. На облачном хранилище (swif) — пароль генерируется один раз и мы его даже не храним.
                                                                                                                • 0
                                                                                                                  А, вы намекаете, что админская почта должна быть на своем правильно настроенном сервере?.. Это интересный point.

                                                                                                                  Алсо, задавать пароль самостоятельно необязательно, а вот забирать из админки по HTTPs — очень хорошо бы.
                                                                                                                  • 0
                                                                                                                    А теперь вопрос: как вы его будете восстанавливать, когда забудете?
                                                                                                                    • 0
                                                                                                                      Предыдущим способом — на почту, после чего сразу поменяю в админке.
                                                                                                                      • 0
                                                                                                                        Так работает большинство известных мне сервисов, плюс они форсят одноразовость того, что высылается на почту. По-моему, это принципиальный момент (все открытое — одноразовое), но с шифрованными каналами между почтовиками вы меня озадачили :)
                                                                                                                        • +2
                                                                                                                          И чем это отличается от отправки пароля? Если кто-то завладел вашей почтой — взлом аккаунта — вопрос времени. Если вы боитесь хранить пароль плейнтекстом в почте — сохраните в любимый password keeper и сотрите письмо. Если вы не доверяете почтовой службе, то она ваш аккаунт сломает, т.к. может перехватить письмо со ссылкой на сброс пароля.

                                                                                                                          То есть безопасности не добавляет — геморроя с хождением по ссылкам — да.

                                                                                                                          • 0
                                                                                                                            Да, почта — это святое, считаем, что она моя.

                                                                                                                            Хранить не буду, сотру, да.

                                                                                                                            А вот в плане передачи в открытом виде, почтовой службе (и всем промежуточным узлам) — и впрямь не доверяю, также как и ОПСОСу, передающему SMS-ки.

                                                                                                                            Поэтому что почтой, что SMS-ками — стоит передавать только одноразовые и короткоживущие секреты.

                                                                                                                            Я не то что бы прям криптоаналитик, просто вижу, что подобная схема внедряется чуть менее, чем везде вокруг (веб-сервисы, банки).
                                                                                                                            • 0
                                                                                                                              Хех, и как вы думаете, сколько промежуточных узлов между вашим почтовым сервером и нашим? Отвечаю: 0. Наш сервер обращается по MX к вашему и передаёт почту.

                                                                                                                              Если же вы говорите про узлы сети, то…

                                                                                                                              en.wikipedia.org/wiki/STARTTLS

                                                                                                                              У меня ни разу в продакте не было почтового сервера, который бы не умел TLS.
                                                                                                                              • 0
                                                                                                                                Угу. Вобщем, при такой схеме никакое гмыло лучше не использовать (мало ли, что он там «удаляет», когда я его прошу), а хостить свою почту на своем сервере на своем домене. У другого, что ли, хостера? ;)