Дельта 2014

[2 1]

господа, кто менял пин в банкомате? как дельта это проводит по счету? .. если я завтра через кеш-ин пополню карту на 5 грн. и сразу сменю пин-код - не вгонить ли меня Дельта в теховер?

Это ещё что! У моего знакомого строителя на кредитке сзади на полосе написан пин код ручкой. так мало того - он в Эпицентре даёт карту касирше и говорит: "там сзади написан ПИН-окд, набери сама, не ипи мне моск"

Ха-ха. А я давно написал ПИН (левый) на одной из своих карт . Пин - пину рознь

Уважаемые клиенты!
спасибо за доверие и внимание к нашему банку и сервисам. Мне очень неприятно, но я должна согласиться, что работа нашего ИБ далека от совершенства, действительно присутствуют сбои и достаточно частые "технические моменты". Но, в тоже время, должна отметить, что, как правило, они носят не долгий характер и быстро устраняются. При этом, вопросы нестабильности работы сервиса вынесены на самый высокий уровень (слежу за этим лично). Поверьте, что стабилизация работы сейчас приоритет №1, разработан план мероприятий, который в данный момент находится в реализации.

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

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

Есть еще т.н. High Availability - это способ проектирования системы, в основе которого лежит гарантирование времени доступности сервиса, несмотря на плановые перезагрузки, обновления и обслуживание системы. Обычно при проектировании таких сервисов задается максимальный интервал в течении которого сервис может быть недоступен. Например гарантируется, что сервис может быть недоступен не более чем 30 минут в месяц.

Такие сервисы обычно состоят из двух дублирующих - ведущего (master) и ведомого (slave). Более критические системы, которые не допускают даже краткосрочного downtime, могут содержать три и более дублирующих сервисов.
Ведущий сервис обрабатывает запросы пользователей, а ведомый работает в режиме "на подхвате". Другими словами, ведомый сервис не обслуживает пользователей, а только мониторит операции происходящие в ведущем и таким образом постоянно поддерживает у себя последнее актуальное состояние в соответствии с ведущим.
Если происходит сбой или останов одного сервиса, ведомый сервис тут-же на лету подхватывает на себя роль ведущего сервиса, продолжая без пауз обрабатывать запросы пользователей. Это дает возможность обслужить и исправить неисправности сломавшегося сервиса и запустить его снова. Исправленный сервис становится ведомым и в случае чего, снова может подхватить на себя роль ведущего.
Аналогично обрабатываются обновления системы. Таким образом на весь период обновления/обслуживания системы, гарантируется непрерывное предоставление услуг.

Очень важна т.н. Scalability (масштабируемость) сервиса. Т.е. должна быть изначально предусмотрена возможность наращивания мощности в зависимости от нагрузки. Это дает возможность платить в каждый момент времени только за тот объем ресурсов (вычислетельные мощности, объем дискового пространства, пропускная способность), который нужен на данный момент времени. Такие ресурсы можно заказывать у т.н. облачных провайдеров (см. Cloud computing). Если нагрузка выростает - платим за больший объем ресурсов и имеем большую мощность. Если нагрузка падает - платим за меньший объем ресурсов и экономим. Облачные провайдеры позволяют полностью избавиться от ненужных проблем с техническим обслуживанием серверов и сопутствующего железа, сосредоточившись на обслуживании самого сервиса. При этом иметь возможность очень быстро менять масштабы сервиса в зависимости от текущих потребностей. Облачные провайдеры часто сами решают такие проблемы как перебои с подачей электроэнергии, доступностью интернет соединений и поломки серверов. Для этого у них есть несколько независимых источников электроэнергии, включая дизель генераторы, несколько независимых каналов широкополосного доступа в интернет.

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

Амвросий начали правильно, но тут что забылись:

Это дает возможность платить в каждый момент времени только за тот объем ресурсов (вычислетельные мощности, объем дискового пространства, пропускная способность), который нужен на данный момент времени. Такие ресурсы можно заказывать у т.н. облачных провайдеров (см. Cloud computing). Если нагрузка выростает - платим за больший объем ресурсов и имеем большую мощность. Если нагрузка падает - платим за меньший объем ресурсов и экономим. Облачные провайдеры позволяют полностью избавиться от ненужных проблем с техническим обслуживанием серверов и сопутствующего железа, сосредоточившись на обслуживании самого сервиса. При этом иметь возможность очень быстро менять масштабы сервиса в зависимости от текущих потребностей.

Даже если отбросить сказки маркетологов о экономической выгоде чужих облаков, Дельта, как банк, не может доверять свои (и наши) данные третьим лицам. Более того, даже к датацетрам для банков у НБУ есть свои требования (не знаю насколько их придерживаются). Потому облака придется иметь "свои".
И вообще, вы так описали, что кажется что вы или не в теме, или это тонкая реклама De Novo)

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

Это все есть у любого сколь-либо приличного ДЦ.

напишите абракадабру для прямого выхода с пином плиз )))

Тут

myDELTA работает и почти не тормозит! Может жизнь налаживается?

sola

0800500600pp1234

- это просто латинские буковки 'p'?

[1 1]

sola

0800500600pp1234

- это просто латинские буковки 'p'?

да, символ "паузы" в телефоне
в некоторых телефонах нужно использовать символ "," (или "р" изменится на него автоматически)

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

Сейчас дискуссия развернется....
Естественно при выборе систем, такие требования предъявляются и разработчик естественно говорит, что его решение всему этому удовлетворяет и даже архитектуру показывает и тесты разворачивает. На первый взгляд все есть. Самый главный вопрос, а где она так работает с таким количеством клиентов? И тут начинаются разные интересные ответы и самый распространенный из них : "система не имеет, пока, такого опыта". Если взять подобное решение с опытом эксплуатации на больших объемах, то придется добавлять к цене нули, как в программное так и в аппаратное обеспечение. Причина, такие системы проектировались 10 лет назад и в них вложены человеко/века и дешево они не стоят. Но каждый новый разработчик скажет, что старье брать не нужно и его система будет работать на ПС, ну максимум на 2-х, поскольку написана на современных технологиях . Итак, вы готовы рискнуть и берете систему с хорошей архитектурой и... как обычно упираетесь в качество кодирования и качество разработки. Как в нашем случае, при исправлении ошибки №58, вместе с патчем накатывается ошибка №50 (ну взял разработчик не тот релиз), и вы снова начинаете ломать голову в чем же проблема. Или смотрите исходный код, а там распараллеливание не используется, хотя архитектура предусматривает. И все просто, программист не знал как это сделать, а архитектор предусмотрел и базы спроектировал... это реалии жизни. Исправить все это может только кропотливый труд и время. Или опять махнуть рукой и "все поделить" в смысле поменять

Что бы это значило?

http://fotohost.org/images/a165767e-11kB.png