http://it.themarker.com/tmit/article/13276
Полную статью на иврите можно найти по ссылке выше. В кратце, речь идёт о следующем.
Система HLR, это система в которой хранится вся информация о клиентах (Cellcom, в данном случае). От его идентификации, до какими программам он пользуется. Существует две копии этой системы, которые синхронизируются между собой. Используются они как для того, чтобы разделять нагрузку между собой, так и для (online) backup-а (резервной копии). По-мимо этого существует ещё одна резервная копия информации (offline), которая делается, скажем, раз в день.
Раз в несколько месяцев Cellcom добавляет какой-то новый сервис для своих клиентов, например, песню во время ожидания. Для этого нужно изменить структуру хранения данных в HLR. Перед тем как запустить скрипт, а он запускается online, т.е. без остановки системы, который делает это изменения нужно, согласно процедуре Cellcom-а, отключит синхронизацию между двумя копиями HLR. Это нужно для того, чтобы, если что-то пойдёт не так, перенаправить весь трафик на неиспорченную копию, пока неполадка будет устранятся, чтобы клиенты не пострадали. Первый промах, Cellcom-а, заключает в том, что синхронизация не была отключена.
Так вот подобный скрипт быд запущен в ночь со вторника на среду на прошлой неделе (см. первый квадратик справа налево). Это изменение привело к порче данных и поломке в системе (см. второй квадратик). Из-за того, что синхронизация не было отключена данные были испорченные на обоих копиях HLR, т.е. online backup-а не осталось. Это ситуация, которая сложилась утром (см. первый квадратик справа в нижней строчке). В этот момент было два возможных решения сложившийся ситуации. Первый выход: использовать offline резервную копию, т.е. отключить обе копии HLR, загрузить информации с резервной копии и включить всё снова. Второй выход: сделать reverse engineering тому, что сделал скрипт и попытаться починить это online. Оказывается, в пике, который случился в 13:17 (см. второй квадратик в нижней строчке) около 40% разговоров все ещё удавалось осуществить. Помимо этого, использование offline backup-а приведёт к потере информации, которая была получена после него (мой комментарий, с другой стороны, зачем тогда вообще он нужен, если им не пользоваться? Более того, именно для таких непредвиденных ситуаций он и предназначен и приведённые выше минусы это та цена, которую ты заранее был согласен заплатить). Помимо этого, весь этот процесс займёт несколько часов. Cellcom выбрал вторую опцию, делать reverse engineering тому, что сделал скрипт и попытаться починить это online. Этот выбор сопряжён с риском, т.к не известно сколько времени займёт устранение поломки. В Cellcom-е надеялись, что это займёт меньше времени, и количество пострадавших клиентов будет тоже меньшим. Однако, только в 21:15 (см. третий квадратик) проблема была устранена (мой комментарий, количество времени явно больше, чем с использованием offline backup-а, однако количество пострадавших клиентов, возможно, всё-таки меньше, особенно учитывая то, что после 13:17 количество успешных разговоров росло и уже в 16:00 достигало 66%).
Не синхронизация, а репликация.
ReplyDelete