Банк аутсорсит свои проекты многим подрядчикам. «Внешники» пишут код, потом передают результаты в не совсем удобном виде. Конкретно процесс выглядел так: они передавали проект, который прошёл функциональные тесты у них, а затем тестировался уже внутри банковского периметра на интеграцию, нагрузку и так далее. Часто обнаруживалось, что тесты фейлятся. Тогда всё уходило обратно внешнему разработчику. Как вы можете догадаться, это означало большие сроки исправления ошибок.

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

Откуда появилось Sec? Безопасность банка выставила высокие требования к тому, как внешний подрядчик может работать в сетевом сегменте, какой у кого доступ, как и кто работает с кодом. Просто ИБ ещё не знала, что когда подрядчики работают снаружи, мало какие банковские стандарты соблюдаются. А тут за пару дней надо их начать соблюдать всем.

Одно простое откровение, что подрядчик имеет полный доступ к коду продукта, уже перевернуло их мир.

В этот момент и началась история DevSecOps, про которую я хочу рассказать.

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

Случай всплыл в памяти по ходу написания статьи. Уже давно собирался рассказать о специальной софтине для сбора всяких инвентаризационных штук с железок — KACE. С ней я знаком как минимум пару лет и не раз приходилось поработать на практике. Сейчас сошлись звезды, мысли собрались в кучу и, наконец, пишу как эта штука может быть полезна для контор от нескольких рабочих станций до многотысячных парков ИТ-оборудования. Вещь простая как валенок и функциональная как микроволновка с грилем и конвекцией, а развернутой статьи на Хабре про нее до сих пор не было.

Источник

По моим оценкам, в мире может существовать сотня-другая систем мониторинга (если у вас есть более точное аргументированное число — приглашаю в комментарии). Это и облачные системы, on-premise, коммерческие, бесплатные, для сети, инфраструктуры и так далее и по всем фронтам. Среди них есть те, что поддерживают создание сервисно-ресурсных моделей. Это такие древовидные штуки, к узлам которых привязаны элементы бизнес-системы: веб-серверы, базы данных, серверы приложений, коммутаторы и много других страшных слов. Каждый дочерний элемент влияет на родительский. Например, если на каком-то сервере превышен порог использования оперативной памяти, создается событие (допустим, критичности Critical — красное), которое влияет на объекты выше по структуре сервиса.

Многие организации привязывают доступность бизнес-системы к доступности бизнес-процесса. Если бы я считал SLA, получилось бы, что доступность ИТ-системы упала до нуля (в момент превышения порога по памяти на каком-то там сервере), а бизнес-процесс остановился. Но это же не так!? Внизу дерева может быть кластер или, вообще, забивание памяти под завязку — нормальный режим работы системы. Короче, задача звучит так: как правильно рассчитывать доступность бизнес-процесса и не оглядываться на некритичные события от компонентов бизнес-систем? Её и разберем.

Аналитическая компания Gartner ежегодно проводит анализ поставщиков решений в различных ИТ-областях. Свои исследования они сводят в квадранты, размещая компании в порядке их соответствия требованиям Gartner. Сегодня расскажем о квадранте ITSM-решений за 2017 год. Поэтому, если вдруг вы решили, что нынешнее средство автоматизации (сервис деск или еще что-то) вам не подходит, – дочитайте статью до конца. Мы работаем с некоторыми из этих поставщиков, знаем о них немного больше, чем пишет Gartner, но в общем расклад игроков именно такой.

Источник

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

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

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

Посвящается всем кто пользуется банковскими услугами.

«Пожалуйста, подождите, информация подгружается» — сообщает девушка на том конце провода. При звонке в банк, в такие моменты, мысленно готовишься ожидать на линии непредсказуемое количество времени. Но вот проходит каких-то жалких 5 минут и к вам возвращаются с ответом. Самое забавное, что они потом еще просят оценить качество обслуживания. А у тебя уже десятый пропущенный вызов по второй линии и пара смс с проклятиями. Ну с кем не бывает? Зависания или задержки в работе банковского программного обеспечения были, есть и будут. Код несовершенен, и штатная работа софта не может быть гарантирована его производителем. Разумеется, каждый производитель ПО стремится устранять баги по мере их обнаружения, но не всем удаётся делать это оперативно. Обработка пользовательских данных, повышение нагрузки на бизнес-приложение, обновления операционной системы генерят непредсказуемые ошибки. В статье расскажем как мы заснифферили пользовательский трафик и помогли крупному российскому банку выявить проблемы софта.