Банк «Санкт-Петербург» переводит ключевые IT-процессы в Yandex.Cloud («Яндекс.Облако»)
В рамках партнёрства между Банком «Санкт-Петербург» и с облачной платформой «Яндекса» (Yandex.Cloud) Банк перемещает часть ключевых IT-процессов в Yandex.Cloud.
Это позволит Банку повысить эффективность инвестиций в IT благодаря переводу затрат на IT-проекты из капитальных вложений в операционные. Кроме того, повысится скорость выделения инфраструктуры под новые проекты и получения конкретных инструментов для создания новых цифровых продуктов и сервисов. При этом Банк переводит в облако только процессную, функциональную часть программного обеспечения. Все базы данных, информация о клиентах и финансах остается исключительно внутри Банка.
Переход в облака позволит уменьшить затраты на поиск и оплату конкретных узких IT-специалистов, способных разворачивать соответствующую инфраструктуру, поддерживать специальные IT-инструменты и разработки. Yandex.Cloud станет для Банка не только инфраструктурным партнером, но и поставщиком готовых решений.
На сегодняшний день завершен пилотный проект по миграции IT-процессов в облако. Пилот подтвердил эффективность и безопасность работы в Yandex.Cloud. В дальнейшем в облаке планируется развернуть часть общедоступных клиентских сервисов.
Старший вице-президент по информационным технологиям Банка «Санкт-Петербург» Александр Рыбаков:
«Облачные технологии в последние годы значительно продвинулись в плане надежности и безопасности и являются очевидным инструментом для повышения эффективности бизнеса. На данном этапе, облачные технологии для нас – это переход на другой технологический формат с точки зрения работы с IT-инфраструктурой, включая подход «инфраструктура как код» (Infrastructure As Code, IaC). Про IaC слышали все специалисты, а мы одни из первых начали работать в этой парадигме. Это был один из самых интересных шагов проекта — новая концепция, и мы уже на практике оценили ее преимущества. Одновременно с проработкой новых технологических инструментов, на первом месте для нас находится вопрос безопасности. В данном случае у Yandex.Cloud есть ряд преимуществ. Это российская платформа, а поставщик — российская компания. У компании есть все необходимые сертификаты по защите информации, включая сертификацию по PCI DSS. Наши центры обработки данных соединены выделенным защищенным каналом связи. Кроме этого, архитектурное решение по переносу сервисов в Яндекс предполагает, что база данных с информацией по клиентам и другие информационные ресурсы остаются на площадке Банка, а в облако мы переносим только логику и реализацию сервисов. Это означает, что с точки зрения защиты персональных данных клиента ничего не меняется. Аналогично с антифрод-решениями».
Дмитрий Родионов, менеджер по работе с ключевыми клиентами Yandex.Cloud:
«Для нас проект с Банком «Санкт-Петербург» стал ценным опытом, ведь проекты в финансовой сфере всегда отличает скрупулезная работа над всеми сетевыми схемами, решение вопросов информационной безопасности. Здесь также критически важен вопрос отказоустойчивости, надежности работы всей системы. Идеология использования публичного облака — разделение ответственности между поставщиком этой технологии и клиентом. Поэтому на стороне своей инфраструктуры мы следуем лучшим практикам на рынке как в части выстраивания процессов защиты, так и в части технических мер обеспечения безопасности. Также на регулярной основе мы проходим множество аудитов соответствия требованиям различных стандартов, – таким образом мы постоянно совершенствуем свои меры защиты и упрощаем выстраивание соответствия этим стандартам для наших клиентов. Данный проект наглядно показал, что для успеха облачной миграции очень важно, чтобы каждый из партнеров фокусировался на том, что он хорошо умеет делать. На оперативность проекта миграции в облако влияют два главных аспекта: возможность максимально автоматизировать для клиента работу с ресурсами и сервисами и наше стремление делиться опытом и лучшими практиками. Когда такая синергия происходит, мы получаем очень интересные проекты, как в случае с Банком «Санкт-Петербург».
Хотя суд заморозил строительство объекта на Звенигородской ул. по жалобе проектировщика. На днях был выдан новый градплан участка, как отмечается в реестре КГА, с целью строительства.
Театр уже принимались строить в 2016 году. Здание удалось возвести в конструкциях, но в итоге работы остановились. Одной из причин стал конфликт с разработчиком архитектурного проекта, ООО "Архитектурная мастерская Мамошина" (АММ). С этой компанией не расплатился за работу генпроектировщик, АО "Театрально–декорационные мастерские" (ТДМ). Сначала зодчие выясняли отношения с ним, но он обанкротился. Так что судиться пришлось уже с госзаказчиком, которому ТДМ передал проект.
В марте 2020 года АММ добилась в 13–м арбитражном апелляционном суде запрета на использование своего проекта, а также выплаты компенсации 22,4 млн рублей ("двукратный размер стоимости экземпляра произведения"). В августе того же года решение устояло в Суде по интеллектуальным спорам (кассационная инстанция).
Минстрой попытался ещё раз обжаловать вердикт, но в феврале нынешнего года Верховный суд отказался передавать дело для пересмотра в свою коллегию по экономическим спорам. Тем не менее архитектурная мастерская пока не смогла получить деньги.
Между тем по заказу Северо–Западной дирекции по строительству, реконструкции и реставрации (ныне ликвидирована, преемником является "Единый заказчик в сфере строительства" Минстроя) проект был частично переработан и в октябре 2020–го вновь прошёл экспертизу (см. "ДП" № 174–175 от 27.11.2020).
Хотя, как говорил Михаил Мамошин, облик здания сохранился, в списке проектировщиков, по данным Единого государственного реестра заключений, АММ уже не значится. В связи с этой экспертизой мастерская инициировала ещё одно судебное разбирательство.
Компания требовала с заказчика 2 млн рублей за неисполнение требования о запрете использования проекта, а также по 50 тыс. рублей за каждую неделю неисполнения этого требования начиная с даты подачи ходатайства.
В июне нынешнего года Арбитражный суд СПб и ЛО удовлетворил требования частично. Он пришёл к выводу, что фактически заказчик использовал проект только в период проведения экспертизы.