FAQ: Информационные Технологии (ИТ)

The Lokad app — это веб-приложение, предоставляемое по модели SaaS (Software as a Service). Цель Lokad — предоставить предиктивную аналитику для оптимизации цепочки поставок (лучшие запасы, лучшие цены и т.д.). Приложение Lokad предназначено для использования в качестве аналитического слоя, работающего вместе с транзакционными системами (ERP, WMS, CRM и т.д.). Оно предлагается за фиксированную ежемесячную абонентскую плату, которая обычно включает само приложение и профессиональные услуги. Эти профессиональные услуги, предоставляемые инженерами Lokad (специалистами по цепочке поставок), почти полностью снимают необходимость в технической поддержке со стороны IT-отдела по данному вопросу. Единственный ключевой вклад, который ожидается от IT-отдела — настройка конвейера данных для передачи файлов (по SFTP или FTPS) в Lokad, а также, возможно, повторная интеграция сгенерированных результатов.

Целевая аудитория: IT-отдел
Last modified: November 30th, 2023

Технический обзор

Приложение Lokad поддерживает многопользовательский режим. Каждый клиент (т.е. учетная запись) имеет собственную выделенную файловую систему и отдельное хранилище кода. К файловой системе можно получить доступ через FTPS, SFTP и веб-интерфейс. Эта файловая система рассчитана на работу с большими файлами (до 100 ГБ на файл) и поддерживает версионирование данных (как в Git). Хранилище кода используется для размещения скриптов Envision. Envision — это проприетарный DSL (Domain Specific Programming Language), разработанный Lokad. Этот DSL в значительной степени адаптирован к задачам предиктивной оптимизации. Скрипты Envision используются для проведения основных числовых анализов (включая алгоритмы машинного обучения, решатели и т.д.) и для создания информационно насыщенных панелей.

Приложение полностью разворачивается каждый вторник с 10:00 до 14:00 (по времени Парижа). Время простоя обычно не превышает 5 минут. Lokad полностью берёт на себя ответственность за все вопросы, связанные с версионированием.

От IT-отдела не требуется осваивать конкретные технологии стека Lokad. Однако, если вам интересно, существует полная техническая документация.

Обзор вклада IT

Мы ожидаем, что IT-отдел настроит конвейер данных, который будет передавать серию релевантных извлечений плоских файлов в Lokad по SFTP или FTPS. Извлечения выполняются на транзакционных системах (например, ERP). Мы отдаем предпочтение сырым извлечениям таблиц (без фильтрации, без объединения, без преобразований), что требует минимальных усилий. С точки зрения ETL, нам нужна только часть “E” (извлечение) в самой простой форме (прямое копирование). Что касается формата, Lokad совместим с любым разумно табличным плоским файлом.

Ожидается, что конвейер данных будет работать не реже одного раза в день и будет полностью автоматизирован. Объём работы для IT-отдела зависит от масштаба извлечения данных (какие системы? какие таблицы?). Однако, как правило, настройка конвейера данных обычно требует от 15 до 45 человекодней, даже для крупных компаний. После настройки конвейера Lokad обычно требует лишь минимального мониторинга со стороны IT-отдела, что обычно занимает 1–2 человекодня в месяц.

Обзор безопасности

Приложение размещено в дата-центрах Microsoft Azure, расположенных в ЕС. Мы не обрабатываем никаких персональных данных, так как они не требуются для работы. При определении объёма извлечения данных мы исключаем любые столбцы или поля, которые могут содержать персональные данные.

Для аутентификации мы отдаём предпочтение SAML. Мы настоятельно рекомендуем, чтобы пользователи получали доступ к Lokad через федеративную систему идентификации, такую как Azure Active Directory, Office 365 или Google Workspace. Это устраняет все проблемы, связанные с паролями.

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

Для получения дополнительной информации см. Безопасность в Lokad.

Обзор временной шкалы

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

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

Спецификации данных: Вскоре после стартовой встречи специалист по цепочке поставок составляет спецификации данных, необходимые для реализации проекта. Эти спецификации совместно с клиентом рассматриваются и утверждаются. В частности, в этом документе определяется, какие данные будут извлекаться из IT-систем клиента. Как правило, извлечение должно максимально точно соответствовать исходным данным, существующим в IT-системах клиента.

Первая загрузка данных: После утверждения спецификаций клиент загружает первый набор данных на серверы Lokad. Как правило, на этом этапе загрузка ещё не проводится автоматически, так как для согласования деталей спецификаций данных обычно требуется несколько попыток.

Проверка данных: Специалист по цепочке поставок проводит детальное исследование содержимого набора данных клиента. В частности, вводятся проверки, предназначенные для контроля качества данных по различным метрикам. Цель заключается в том, чтобы убедиться, что 1) набор данных корректно обновляется в процессе загрузки, 2) данные точно отражают реальное состояние бизнеса и 3) набор данных достаточно согласован и полон для целей оптимизации цепочки поставок.

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

Промежуточный аудит: Через 6 недель после начала проекта проводится встреча для оценки статуса выполнения проекта. Цель этого «аудита» — как можно раньше выявить проблемы, которые могут возникнуть в процессе реализации, особенно те, которые могут задержать стадию производства. В Lokad этот «аудит» представляет собой обмен информацией между специалистом по цепочке поставок и клиентом, на основе контрольного списка, который специалист по цепочке поставок заранее доводит до сведения клиента сразу после стартовой встречи.

Автоматизация загрузки: После того как обе стороны подтвердят общее качество загруженного набора данных, клиент внедряет автоматизированный процесс, который регулярно передаёт их данные в Lokad — в идеале, ежедневно. В то же время на стороне Lokad логика проверки состояния данных с множеством контрольных проверок запускается после каждой загрузки.

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

Обратная связь и доработка: Запросы клиента на внесение изменений или корректировку различных показателей обычно ведут к тонкой настройке скриптов, разработанных специалистом по цепочке поставок. Существует множество параметров и методов, которые можно применить для того, чтобы адекватно согласовать характеристики оптимизируемой цепочки поставок с логикой оптимизации. Когда методология сама по себе имеет стратегическое значение для клиента, этот вопрос обсуждается между клиентом и специалистом по цепочке поставок.

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

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

Часто задаваемые вопросы (FAQ)

1. Управление релизами

1.1 Как работают релизы в Lokad?

Lokad управляет всеми релизами самостоятельно, что обеспечивает полную прозрачность для клиентов. Любые релизы, которые могут повлиять на клиента, согласовываются с ним — через технические команды клиента — заблаговременно. В общем, Lokad придерживается осторожного подхода к релизам: если запланированный релиз не предоставляет клиенту достаточного времени для подготовки, его временно откладывают.

Релизы Lokad очень детализированы, и дизайн обычно позволяет клиенту отказаться от отдельного технического элемента общего релиза. Таким образом, если необходимо отложить внедрение одного элемента — к которому клиент ещё не готов — общий релиз всё равно может состояться (с внедрением остальных, не затрагивающих элементов).

1.2 Как часто происходят релизы?

Lokad выпускает новую версию каждый вторник, обычно около 11:00 (CET).

1.3 Предоставляете ли вы план предстоящих релизов?

Да, см. Управление релизами 1.2.

1.4 Влечет ли смена версии переустановку или только патч?

Lokad переустанавливает своё решение с помощью автоматизированных средств (скриптов). Мы не применяем патчи к системам в рабочей среде. Если требуется развернуть «патч безопасности», мы переустанавливаем решение обычными автоматизированными средствами.

1.5 Сколько времени занимает применение мажорного релиза?

Автоматизированный процесс занимает примерно 1 час. Реализуется поэтапное разворачивание (поочередно на машинах), так как мы намерены сохранять работоспособность и доступность платформы Lokad во время релиза. Работоспособность в процессе разворачивания обсуждается в Управлении релизами 1.7.

1.6 Кто отвечает за корректное выполнение релиза?

Команда Lokad полностью отвечает за корректное выполнение релиза.

1.7 Есть ли простой во время релиза?

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

1.8 Каков ваш процесс или стратегия тестирования перед релизом?

Lokad использует автоматизированные процессы для тестирования и обеспечения корректности предстоящего релиза. Эти процессы включают обширные наборы автоматизированных тестов (численностью в тысячи); модульные тесты, функциональные тесты, тесты производительности и т.д. Мы также разработали специализированные инструменты, позволяющие воспроизводить целые последовательности исполнения прошлых заданий на платформе Lokad. Эти инструменты позволяют проверить, что скрипты Envision ведут себя идентично до и после релиза. Кроме того, мы можем удостовериться, что показатели производительности существующих скриптов соответствуют установленным ожиданиям, определённым нашими клиентами.

1.9 Есть ли у вас несколько сред?

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

Если цель состоит в том, чтобы запускать (рядом) несколько вариантов скриптов Envision, то один аккаунт Lokad может быть разделён на несколько “окружений”. Если цель состоит в том, чтобы проводить любые виды тестирования, то для временных тестовых целей может быть предоставлен второй аккаунт Lokad. Такой второй подход позволяет изолировать основной клиентский аккаунт (используемый для производства) от этих тестов.

1.10 Сколько различных версий может сосуществовать?

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

1.11 Может ли клиент отказаться от релиза?

Поскольку Lokad — это многопользовательский SaaS, который работает с единой уникальной версией для всех клиентов, отказаться от релиза невозможно. Однако с деловой точки зрения это не имеет значения, поскольку любое “изменение” реализуется посредством выполнения скриптов Envision в рамках решения Lokad.

В случаях, когда выпуск может быть временно отложен, см. Release Management 1.1.

1.12 Есть ли у вас примечания к релизу? Предоставляете ли вы их своим клиентам?

Да. Эти заметки распространяются внутри компании (с нашими специалистами по цепочкам поставок). Если это явно оговорено в контракте, эти примечания к релизу могут быть доступны клиенту. На практике примечания к релизу платформы Lokad интересны только тем, кто работает с кодом Envision.

1.13 Каков процесс запроса изменений в решении?

Большинство наших клиентов пользуются предложением “software + expert”, при котором команда специалистов по цепочкам поставок Lokad отвечает за внедрение и обслуживание решения по цепочке поставок клиента. Такие ситуации называют “supply chain as a service”. В этих случаях клиент регулярно взаимодействует с одним (или несколькими) специалистом(ами) по цепочкам поставок. Кроме того, большинство клиентов участвуют в еженедельном или ежемесячном совещании по управлению для обсуждения текущего состояния решения и необходимых изменений. Этот метод используется Lokad для сбора всех запросов на эволюцию решения и предложения дорожной карты по внедрению изменений.

1.14 Возможно ли администрировать веб-сервис приложения и настраивать его параметры?

Да, в том смысле, что платформа Lokad по своей природе является программируемой. “Аналитическая” логика Lokad принимает форму скриптов Envision — Envision является DSL (предметно-специфичным языком программирования), разработанным Lokad для целей предиктивной оптимизации цепочки поставок.

Таким образом, по сути, каждая отдельная настройка параметров доступна посредством использования скриптов Envision внутри аккаунта.

2. Производительность

2.1 Гарантирует ли ваше SLA (договор об уровне обслуживания) 99.xy% времени работы системы?

Да. SLA является частью нашего стандартного контрактного соглашения. Однако понятие времени работы системы в контексте распределённой вычислительной системы, предназначенной для предиктивной оптимизации цепочек поставок, является сложным. Рассмотрим следующие сценарии: - Данные клиента (ежедневный шаг) поступают в Lokad с задержкой в 2 часа. Это вполне может нарушить обычную эффективность наших эвристических алгоритмов распределения ресурсов. В свою очередь, это может увеличить время выполнения пакетных заданий Lokad (например, 75 минут вместо обычных 60). Некоторые могут посчитать это 15-минутным простоем, но это вне нашего контроля.

• Lokad получает те же данные клиента вовремя, но данные показывают значительное падение уровней запасов. Это вызовет прерывание пакетных заданий (на стороне Lokad) и оповестит специалиста по цепочкам поставок для расследования проблемы. Специалист по цепочкам поставок обнаруживает, что автоматический заказ на пополнение оказался беспрецедентно большим. Он решает, что необходима прямая оценка со стороны клиента. На следующий день клиент подтверждает, что данные о запасах были повреждены и в итоге привели бы к значительной уценке запасов. Некоторые могут посчитать это 24-часовым простоем, но это кажется практически несуразным в данном контексте.

Самая большая опасность для решения по оптимизации цепочки поставок заключается не в том, чтобы немного опоздать; опасность заключается в том, чтобы быть крайне неверным. Как только принято решение по цепочке поставок, например, (ошибочно) запустить производственную партию, его отмена может оказаться чрезвычайно дорогостоящей. Мы призываем наших клиентов не привязываться произвольно к отдельным индикаторам, поскольку такое отношение может стимулировать людей предоставлять некачественную общую работу, если это выглядит как удовлетворение ключевого показателя (например, x.y% времени работы системы).

2.2 Гарантируете ли вы время отклика на запросы пользователей в пределах X секунд?

Да, менее 500 мс, но с оговорками.

Мы разработали нечто, что по сути сводится к «дашбордам с постоянным временем отклика». Под капотом отображение дашборда требует всего одного запроса по сети, а на нашем сервере мы располагаем все данные дашборда вместе, чтобы количество сетевых запросов оставалось небольшим (обычно измеряется однозначными числами). Такой дизайн значительно способствует “гарантии” низкой задержки типичного запроса пользователя при отображении дашборда. Этот выбор также предотвращает перегрузку дашборда множеством плиток, каждая из которых требовала бы отдельного запроса, что могло бы замедлить общий пользовательский опыт.

Что касается продолжительности пакетных заданий, с помощью Envision мы можем дать гарантии — на этапе компиляции — что пакетное задание завершится. Мы также можем гарантировать практически воспроизводимые времена завершения наших пакетных заданий. Эти гарантии достигаются за счет статического анализа и тщательного проектирования языка Envision, что в первую очередь делает возможными определённые виды статического анализа. Такой подход имеет свои ограничения, но он значительно превосходит конструкции, которые вообще не предоставляют никаких гарантий.

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

2.3 Ведете ли вы журналы аудита производительности системы?

Да. Мы собираем очень детальные журналы производительности для всех задействованных вычислительных ресурсов: CPU, памяти, хранилища, пропускной способности и т.д. Эти журналы используются, среди прочего, для того, чтобы убедиться, что новая, ещё не выпущенная версия платформы соответствует нашим ожиданиям в плане производительности. Мы тестируем это, сравнивая производительность новой версии с производительностью предыдущих версий, о чём свидетельствуют эти журналы.

2.4 Возможно ли отслеживать медленные ответы или перегрузку?

Да. Платформа Lokad поставляется с внутренним планировщиком, который может отслеживать своевременное выполнение пакетных заданий. Дизайн Lokad в значительной степени обеспечивает постоянное время отклика для всех запросов — за исключением длительно выполняемых операций, которые рассматриваются как пакетные задания.

Поскольку Lokad является многопользовательской платформой, значительная часть мониторинга производительности недоступна напрямую нашим клиентам (так как охватывает производительность платформы в целом). Как и следовало ожидать, команды Lokad постоянно отслеживают производительность нашей платформы.

2.5 Есть ли у вас балансировщики нагрузки?

Да. Балансировщики нагрузки Lokad в первую очередь предназначены для повышения надёжности, а не для улучшения производительности. Балансировка нагрузки на сетевом уровне осуществляется через сетевой слой облачной вычислительной платформы, которую мы используем (Microsoft Azure). Однако распределение внутренней нагрузки по обработке данных, осуществляемое платформой Lokad, управляется не балансировщиками, а внутренним оркестратором, связанным с нашим компиляторным стеком.

2.6 Используете ли вы пулирование ресурсов, таких как подключения к базе данных, сессии и т.д.?

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

2.7 Поддерживаете ли вы параллельную обработку?

Да. Envision (наш DSL) разработан на основе идеи автоматического параллелизма выполнения. Платформа Lokad активно использует параллелизацию на нескольких уровнях: на уровне ядер процессора с помощью операций SIMD (Single Instruction/Multiple Data); на уровне процессора посредством многопоточного выполнения; и на уровне кластера через распределённые вычисления. Поскольку параллельная обработка является ключевым аспектом дизайна Envision, почти все вычислительные нагрузки, выполняемые на платформе Lokad, по умолчанию получают выгоду от обширной параллелизации без каких-либо дополнительных усилий со стороны наших клиентов или специалистов по цепочкам поставок.

2.8 Поддерживаете ли вы кэширование каких-либо часто запрашиваемых данных?

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

2.9 Сжимаете ли вы данные для уменьшения сетевого трафика?

Да, мы сжимаем большую часть сетевого трафика. Однако мы не можем сжимать весь трафик, так как это привело бы к уязвимости в безопасности, известной как BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH возникает, когда присутствует комбинация из 3 факторов.

1. Ответ сжат.

2. Ответ содержит секрет.

3. Ответ содержит строку, которую может собрать злоумышленник, формирующий запрос.

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

2.10 Проводите ли вы тестирование производительности?

Да. Lokad располагает обширным автоматизированным слоем инструментов, ориентированных на оценку производительности. Этот набор инструментов позволяет нам оценить, до каждого релиза, разницу в производительности между предстоящей версией и версией, которая в настоящее время развернута. Он позволяет нам воспроизводить те же рабочие нагрузки, что наблюдаются в производственной среде, и контролировать полученную производительность; не только в абсолютном времени, но и с учётом всех соответствующих вычислительных ресурсов (памяти, пропускной способности, ввода-вывода, CPU и т.д.).

2.11 Мониторите ли вы производительность на уровне транзакций?

Да. Однако, поскольку платформа Lokad не использует транзакционную базу данных, транзакций для мониторинга (в традиционном смысле) нет. Ближайшим эквивалентом является выполнение скриптов Envision. Для этих скриптов мы контролируем производительность на весьма детальном уровне, что примерно соответствует отслеживанию мельчайших деталей плана выполнения запроса (с точки зрения транзакционной базы данных).

Смотрите Authorization 3.6 и Logging and Monitoring 5.3 в нашей Security документации для получения дополнительной информации о “транзакциях” в решении Lokad.

2.12 Каково влияние на производительность решения при одновременной работе множества пользователей?

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

Однако, поскольку любой отдельный пользователь (при наличии соответствующих системных прав) может инициировать произвольные большие вычислительные нагрузки, количество одновременных пользователей, в лучшем случае, является второстепенной проблемой с точки зрения производительности решения. Что касается предиктивной оптимизации цепочек поставок, пакетные задания, используемые для проведения аналитики, составляют более 99% общей нагрузки. Менее чем 1% остаётся на обслуживание пользовательских запросов.

2.13 Разработана ли система для вертикального и горизонтального масштабирования?

Да. С нашей точки зрения, вертикальное и горизонтальное масштабирование являются взаимодополняющими, и дизайн платформы Lokad использует оба подхода. Внутренний оркестратор — тот, который отвечает за параллелизацию — обычно начинает с вертикального масштабирования, так как оно значительно облегчает колокацию данных. Затем оркестратор использует горизонтальное масштабирование, если нагрузка достаточно велика, чтобы извлечь выгоду от выполнения на нескольких машинах.

2.14 Автоматически ли масштабируются вычислительные ресурсы и хранилище по мере необходимости?

Да. Платформа Lokad является многопользовательской. Благодаря этому мы осуществляем масштабное распределение вычислительных ресурсов с низкой задержкой. Это означает, что автоматическое масштабирование вычислительных ресурсов, предоставляемое Lokad, осуществляется в несколько порядков быстрее, чем разворачивание больших виртуальных машин у облачного провайдера. Автоматическое масштабирование хранилища в значительной степени осуществляется за счёт использования возможностей авто-масштабирования постоянного хранилища ключ-значение, предоставляемого базовой облачной платформой (Microsoft Azure).

2.15 Как ваше приложение управляет требованиями к «Big Data»?

Платформа Lokad была специально разработана для обработки «Big Data». По состоянию на январь 2023 года вся платформа Lokad управляет примерно 1 петабайтом данных по всей нашей клиентской базе. Наша платформа способна обрабатывать отдельные файлы объёмом до 100 ГБ, и мы регулярно обрабатываем таблицы с десятками миллиардов строк. Перейти к Безопасности Lokad 4.10

Этот пункт является особенно техническим и выходит за рамки данного документа. Для подробного объяснения мы рекомендуем 4-частный цикл Виктора Николле о конструкции виртуальной машины Envision.

2.16 Можно ли настроить облачное решение Lokad с учетом жестких ограничений пропускной способности и задержки (на стороне клиента)? Например: пропускная способность = 3 Мбит/с (скачивание) / 1 Мбит/с (загрузка), задержка = 600–800 мс

Да, веб-приложение, разработанное Lokad, спроектировано таким образом, чтобы поддерживать сценарии, когда связь “плохая” (как по пропускной способности, так и по задержке). Эти вопросы решаются, прежде всего, благодаря базовым технологическим решениям в дизайне. Эти архитектурные решения также отличают Lokad от массовых решений. Проблемы с пропускной способностью решаются двумя способами. Во-первых, мы экономим на сторонних JavaScript-компонентах – первоначально требуется загрузить менее 1 МБ ассетов. Во-вторых, платформа предоставляет полный контроль над объёмом данных, включаемых в любой отдельный дашборд. Таким образом, если связь плохая, можно сделать дашборд достаточно “легким”. Что касается задержки, наши дашборды спроектированы так, чтобы упаковать все необходимые данные дашборда в один HTTP-запрос. Это минимизирует трение, возникающее у пользователей при низкой задержке.

2.17 Каковы средние и пиковые показатели пропускной способности данных решения по сравнению с ориентиром в 1 (низкий уровень) и 5 (высокий уровень) сообщений в секунду?

Платформа Lokad не оперирует сообщениями. Аналогично, взаимодействия с платформой Lokad не осуществляются посредством сообщений. Однако пропускная способность имеет значение для быстрой обработки огромных наборов транзакционных данных. Платформа Lokad в совокупности управляет более чем 1 петабайтом данных. Мы регулярно обрабатываем более 1 терабайта в минуту при выполнении больших вычислительных партий.

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

2.18 Какой размер сообщений может обрабатывать решение? Пожалуйста, укажите детали касательно минимальных, максимальных и средних значений.

Платформа Lokad не работает с сообщениями. Ближайший аналог — «плоские файлы». Эти плоские файлы могут быть отправлены в Lokad и получены из неё. Платформа Lokad может обрабатывать файлы размером до 100 ГБ каждый. Однако это не является рекомендуемой практикой, так как обычно это немного громоздко (не для Lokad, а для клиентов, которым придётся осваивать сторонние инструменты для создания и использования больших файлов).

3. Инциденты

3.1 Каков процесс сообщения об инциденте со стороны клиента?

Большинство наших клиентов пользуются пакетом, который включает доступ к нашей команде специалистов по цепям поставок. Эти специалисты являются первым контактным лицом для сообщения об инцидентах. В случае инцидента мы рекомендуем клиентам либо позвонить напрямую своему специалисту по цепям поставок — если проблема срочная, — либо отправить электронное письмо. Специалисты по цепям поставок занимаются управлением инцидентами, включая любые эскалации внутри организации Lokad.

3.2 Предоставляете ли вы систему тикетов?

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

3.3 Поддерживаете ли вы отправку инцидентов в сторонние инструменты?

Да, при условии наличия специального договорного соглашения.

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

3.4 Как вы обеспечиваете высокую доступность?

Lokad стала одной из первых, кто принял облачные платформы (ок. 2010 года) именно для обеспечения высокой доступности. Помимо создания избыточной инфраструктуры (см. Инциденты 3.5), дизайн решения Lokad делает упор на простоту. В отличие от сопоставимых корпоративных программных решений, у нас значительно меньше сложных зависимостей (почти на порядок меньше). Огромным слоем сложности, отсутствующим в нашем решении, является транзакционная база данных. Благодаря меньшему количеству движущихся частей, у нас гораздо меньше режимов отказа, что помогает нам поддерживать высокую доступность для наших клиентов (которые распределены по нескольким часовым поясам).

3.5 Есть ли у вас избыточная инфраструктура (если да, то как)? Избегаете ли вы единой точки отказа?

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

3.6 Как вы восстанавливаетесь после аппаратных сбоев?

Восстановление после большинства аппаратных сбоев выполняется прозрачно облачной платформой, которую использует Lokad. Встроенная избыточность платформы Lokad гарантирует, что временные аппаратные сбои не влияют на время работы системы, пока облачная платформа не перераспределит новый исправный ресурс. Для постоянного хранения данных Lokad использует только те сервисы (например, хранилища ключ-значение), которые сами защищены от аппаратных сбоев с помощью собственных уровней избыточности.

3.7 Есть ли у вас резервное копирование?

Да. У нас есть среда резервного копирования, предназначенная для сценариев восстановления после серьёзных катастроф (выход за пределы простоя на уровне дата-центра). Эта резервная среда полностью изолирована от производственной. Резервная среда может считывать данные из производственной (но не записывать), в то время как производственная среда не может ни считывать, ни записывать данные из резервной.

3.8 Есть ли у вас план восстановления после катастроф?

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

3.9 Поддерживает ли решение восстановление к определённому моменту во времени (PITR) для данных внутри базы данных и за её пределами? Какова целевая точка восстановления (RPO) решения?

Решение Lokad имеет систему непрерывной защиты данных благодаря живому инкрементальному резервному копированию как хранилища событий, так и источника контента. Таким образом, мы можем выполнить восстановление к любому заданному моменту (с точностью до минуты).

У нас целевая точка восстановления (RPO) составляет 1 минуту для катастроф на уровне дата-центра — при условии, что данные не нарушены. Мы достигаем этого благодаря географически избыточной записи нашего постоянного хранилища ключ-значение. Если хранилище ключ-значение окажется скомпрометированным, Lokad восстанавливается из резервного хранилища (содержащегося в максимально изолированной от наших производственных систем среде), также размещённого в другом географическом регионе. В этом случае RPO составляет 12 часов.

3.10 Может ли решение генерировать оповещения о нарушении целостности? Обладает ли решение возможностью добавлять или расширять проверки целостности по требованию?

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

Что касается обработки данных клиентов, Envision (DSL Lokad) обладает обширными возможностями для проверки их качества. С помощью Envision можно проверить целостность и сгенерировать оповещения. Логику можно расширить или изменить любым способом, который клиент сочтет уместным.

3.11 Проводится ли периодическое тестирование резервных копий для проверки корректности восстановления данных?

Да. Архитектура на основе извлечения событий в Lokad, в сочетании с адресуемым хранилищем контента, облегчает тестирование резервного копирования и функции восстановления данных по сравнению с большинством традиционных решений, использующих реляционные базы данных (такие как SQL).

См. также Инциденты 3.7.

3.12 Проводится ли периодическое тестирование планов восстановления после катастроф для проверки их эффективности?

Да. Стратегия развертывания Lokad использует скрипты автоматизации от начала до конца, намеренно сводя к минимуму вмешательство человека — одним заметным исключением является возможность инициировать полное повторное развертывание в производственной среде. Такой механизм автоматизации значительно упрощает тестирование функций восстановления после катастроф.

См. Инциденты 3.8.

3.13 Можно ли выполнять восстановление для отдельных клиентов и/или их сред?

Да. Наш внутренний инструментарий поддерживает возможность восстановления аккаунта выбранного клиента (включая восстановление аккаунта/среды до заданного момента времени). Однако, учитывая, что сама платформа Lokad обладает обширными возможностями версионирования (например, скрипты Envision версионируются, и предыдущие версии доступны из приложения), эта возможность используется редко.

3.14 Соответствуют ли планы резервного копирования и восстановления после катастроф требованиям по RTO (Recovery Time Objective), RPO (Recovery Point Objective) и сценариям катастроф, установленным и согласованным с соответствующими клиентами?

Да. RTO (целевое время восстановления) здесь означает время, в течение которого платформа Lokad может теоретически быть недоступной без нанесения значительного ущерба клиенту, а также время, затрачиваемое на восстановление платформы и её данных для возобновления нормальной работы после значительного инцидента.

RTO сильно зависит от деталей конкретных процессов, поддерживаемых/предоставляемых Lokad. Например, клиент, который использует Lokad для планирования ежемесячных заказов за границей, может иметь RTO в 1 неделю. В то же время клиент, полагающийся на Lokad для оптимизации ежедневной доставки товаров со склада в несколько магазинов, может иметь RTO в 1 час.

На практике можно внедрить различные технические меры, чтобы значительно улучшить RTO (т.е. сократить предполагаемый период простоя). Например, решения по переключению могут быть вычислены заранее. Эти решения могут быть использованы в случае недоступности платформы Lokad. По сравнению с «обычными» оптимизированными решениями, решения по переключению могут демонстрировать незначительно снижённую производительность поставок, поскольку, по определению, они не будут использовать абсолютно актуальные данные.

Для наших управляемых аккаунтов именно специалист по цепям поставок в Lokad несёт ответственность за совместную разработку процесса с операционными командами клиента, который обеспечивает высокий RTO, а также минимальное воздействие на бизнес в случае реального инцидента. С нашей точки зрения, эта задача прежде всего является задачей цепи поставок, а не IT-проблемой.

См. также Инциденты 3.9.

3.15 Если дефект не воспроизводится в тестовой среде, может ли Lokad проверить, что дефект действительно имел место, по логам и сопутствующим данным, а также обеспечить его исправление в соответствии с соглашением об уровне обслуживания (SLA)?

Да, дефекты могут быть воспроизведены в наших средах. Строгая воспроизводимость всех состояний данных и всех вычислений является основным принципом дизайна платформы и архитектуры Lokad. Например, файловая система внутри платформы Lokad полностью версионируется (например, как Git), именно для решения этой проблемы.

Следует отметить, что логи эффективнее для устранения тривиальных проблем, таких как простой сервера. Когда же дело доходит до устранения сложных проблем и дефектов в среде с большими объёмами данных — где задействованы терабайты данных — логи часто оказываются недостаточными.

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

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

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

3.16 Ведете ли вы записи обо всех запросах на обслуживание и звонках в службу поддержки (включая категорию каждого звонка), поступающих от клиентской компании? Включают ли записи: личность звонящего и вызываемого; природу сообщаемой ошибки, проблемы или инцидента; время ответа Lokad; исход звонка; решение; время на решение; и доступность системы?

Да, платформа Lokad имеет возможности управления задачами/тикетами/инцидентами, которые обеспечивают предоставление перечисленных деталей.

Что касается «решений», стоит отметить, что количественная философия цепей поставок Lokad (QSC) направлена на поиск наиболее финансово выгодного компромисса при решении проблемы. Технически QSC не является подходом «устранения проблемы», так как проблемы в цепях поставок не «устраняются», а смягчаются за счет принятия экономически обоснованных компромиссов.

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

4. Архитектура

4.1 Какие языки программирования вы используете?

Платформа Lokad разрабатывается на C#, F# и TypeScript. Платформа также включает Envision (DSL Lokad), который используется для реализации решений цепей поставок, специфичных для клиента.

4.2 Какой средства разработки вы используете?

Команды разработчиков программного обеспечения Lokad используют Microsoft Visual Studio. Команды специалистов по цепям поставок используют саму платформу Lokad, которая имеет собственный набор средств разработки.

4.3 Какую операционную систему вы поддерживаете?

Lokad — это веб-платформа, и мы поддерживаем все операционные системы, имеющие доступ к современному веб-браузеру (например, Firefox). Внутренне платформа Lokad совместима как с Linux, так и с Microsoft Windows, хотя все наши производственные системы развернуты под Linux (Ubuntu).

4.4 Какую систему управления базами данных вы используете или поддерживаете?

Lokad поддерживает все системы управления базами данных, которые могут экспортировать данные в плоских файлах. Это включает практически все системы баз данных на рынке, включая устаревшие модели. Внутренне Lokad не использует систему баз данных, а применяет хранилище ключ-значение. На момент написания (январь 2023 года) мы используем Blob Storage, предоставляемый Microsoft Azure.

4.5 Какую систему кэширования вы используете?

Lokad разработала собственные подсистемы кэширования на C#/.NET. Эти подсистемы тесно интегрированы с остальной частью решения и не являются традиционными системами кэширования, предназначенными прежде всего для смягчения проблем производительности с реляционными базами данных (которые отсутствуют в Lokad).

4.6 Как решение работает с сертификатами?

Lokad использует Let’s Encrypt для автоматизированного обновления сертификатов.

4.7 Каковы технические требования для использования решения?

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

4.8 Перечислите любые дополнительные лицензии сторонних производителей, необходимые для эксплуатации решения Lokad (например, ОС, SQL,…).

Н/Д. Для работы Lokad не требуется никаких лицензий сторонних производителей. Существует широкий спектр инструментов с открытым исходным кодом, поддерживающих интеграцию Lokad (то есть передачу плоских файлов через FTPS или SFTP); следовательно, для получения преимуществ от платформы Lokad не требуется ни прямая, ни косвенная лицензия сторонних производителей.

4.9 Требует ли сервис каких-либо плагинов для браузера или специального программного обеспечения?

Lokad — это веб-приложение. Оно не требует плагинов для браузера или специального программного обеспечения.

4.10 Какие входящие и исходящие интерфейсы имеет приложение?

Решение Lokad предоставляет веб-интерфейс — доступный через HTTPS — и файловые протоколы, а именно SFTP и FTPS.

4.11 Как вы гарантируете, что не происходит утечка данных между арендаторами?

Решение Lokad разделяет данные арендаторов благодаря своему дизайну, что гарантирует отсутствие утечек данных (даже случайных). Более того, весь код, выпускаемый в продакшн, проходит рецензирование коллег, что обеспечивает дополнительный уровень защиты. Наконец, мы направляем исследователей безопасности (людей, проводящих пентесты) для детального изучения возможности утечек данных. Мы предоставляем им доступ к нескольким аккаунтам Lokad — в специализированной и полностью изолированной среде, максимально похожей на рабочую — чтобы они могли тщательно проверить это свойство нашей платформы.

4.12 Можно ли контейнеризировать решение?

Да, но контейнеризация платформы Lokad дает мало или не дает никаких преимуществ. Контейнеризация имеет смысл, когда имеются сложные зависимости (например, транзакционная база данных, изолированная система кэширования и т.д.). Мы не используем контейнеры ни в продакшене, ни в разработке, что повышает нашу безопасность за счет исключения целых классов уязвимостей. Вместо этого мы сохраняем решение достаточно простым, чтобы развертывание можно было осуществить даже с помощью небольших shell-скриптов.

4.13 Можно ли отделить компоненты графического интерфейса от бэкенда?

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

4.14 Поддерживает ли приложение Lokad функции локализации (например, смену языка)?

Да, приложение поддерживает функции локализации. Все пользовательские интерфейсы, созданные платформой Lokad, могут быть локализованы на любой язык. В частности, весь технологический стек использует кодировку UTF-8, чтобы обеспечить поддержку всех наборов символов, выходящих за рамки латиницы. Таким образом, любой пользовательский интерфейс, созданный платформой Lokad, может быть переведен — после поставки — на другой язык.

4.15 Возможно ли для конечных пользователей обновлять или создавать новые переводы после получения обработанных данных от Lokad?

Да, см. пункт 4.14 выше.

4.16 Имеет ли ваша система встроенную справку? Если да, то на каком(их) языке(ах)?

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

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

4.17 Является ли веб-приложение адаптивным?

Веб-приложение Lokad, а также сопутствующие материалы (такие как техническая документация) разработаны с учетом адаптивности. Однако некоторые расширенные возможности, например, редактирование кода, непрактичны для мобильных устройств и/или планшетов. Таким образом, дизайн нацелен на максимальную адаптивность для предполагаемых действий, выполняемых на ПК и небольших устройствах, соответственно.

4.18 Если ваша система является веб-приложением, какие браузеры и их версии вы поддерживаете? Какой минимальный стандарт интернет-браузера вы требуете?

Lokad — это веб-приложение, и мы поддерживаем основные «вечнозеленые» браузеры, такие как Chrome, Firefox и Safari. Мы не пытаемся поддерживать старые браузеры по соображениям безопасности, так как их поддержка косвенно угрожает нашим клиентам. Проще говоря, уязвимый браузер может быть использован злоумышленником для утечки данных. При этом мы довольно консервативны в отношении новых возможностей браузеров. Как правило, мы избегаем поддержки любых возможностей браузера, которые не были приняты всеми основными браузерами минимум в течение 1 года.

4.19 Для мобильных и планшетных приложений, какую ОС (и версии) поддерживает Lokad?

Н/Д. Поскольку Lokad — это веб-приложение, предоставляемое как SaaS, нашим клиентам не требуется поддержка конкретной ОС. Внутри Lokad разрабатывается под Windows, в то время как вся наша продакшн-среда в облаке работает под Linux. Таким образом, мы уверены в широкой портируемости решения Lokad. Хотя в настоящее время мы не видим необходимости изменять эту настройку, в случае появления убедительных доказательств мы адаптируемся соответствующим образом.

4.20 Может ли веб-приложение Lokad отправлять уведомления конечным пользователям? Если да, то какая технология/протокол используется?

Да, Lokad обладает возможностью отправлять уведомления через программируемые HTTP-хуки. Эти хуки можно использовать для интеграции с системами третьих сторон, часто уже используемыми в компании клиента, для отправки уведомлений по электронной почте или любых других альтернативных уведомлений, считающихся подходящими. Обычно хуки также используются, чтобы сигнализировать о наличии данных, доступных для получения с платформы Lokad через SFTP или FTPS.

4.21 Есть ли общие элементы в решении, которые характерны для всех клиентов (например, функции мониторинга, решения для резервного копирования или управления обновлениями и патчами и т.д.)?

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

4.22 Позволяет ли решение отправку сообщений на несколько адресатов (т.е. возможность отправлять сообщение более чем одному получателю или приложению)?

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

4.23 Используют ли все критические системы и компоненты один и тот же источник времени (NTP) или синхронизируют свои часы иным надежным способом?

Да. Lokad использует стандартный NTP-сервис, входящий в состав Ubuntu — ntp.ubuntu.com. Более конкретно, в качестве службы синхронизации времени запускается ntpd, который синхронизируется с внешним NTP-источником времени, доступ к которому осуществляется по сети.

4.24 Существует ли список учета активов или база данных управления конфигурациями (CMDB)?

Да, у нас имеется программное обеспечение для управления ИТ-активами, которое поддерживает наши процессы. Эта платформа помогает нам поддерживать исчерпывающий список учета активов и выполняет функции базы данных управления конфигурациями (CMDB). С помощью этой системы наши команды могут быстро отслеживать, управлять и распределять аппаратные и программные ресурсы по всей организации, что позволяет оперативно реагировать на изменения, обновления или потенциальные проблемы.

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

4.25 Завершается ли каждое соединение с внешней сетью на файрволе (например, Интернет, сети партнеров)?

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

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

Более того, наличие строгих файрволов может быть контрпродуктивным в практическом плане. Наш опыт показывает, что такие системы часто побуждают сотрудников искать альтернативные способы доступа и обмена информацией. Обычно это связано с обходом корпоративной сети (и, соответственно, отсутствием возможности мониторинга), использованием личных 4G или 5G соединений с их собственных устройств. Такие практики невольно увеличивают риск нарушений безопасности и утечек данных.

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

4.26 Имеет ли сеть DMZ (демилитаризованную зону), через которую передаются, обрабатываются или хранятся критически важные системы (например, веб-серверы, DNS, службы каталогов и удаленный доступ), а также данные клиентов?

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

Эта модель не полагается на DMZ, а работает по принципу «никогда не доверяй, всегда проверяй». Каждый запрос на доступ проходит проверку и аутентификацию, независимо от его происхождения, будь то изнутри или снаружи организации.

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