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

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

Целевая аудитория: ИТ-отдел
Последнее изменение: 30 ноября 2023 года

Social-IT_FAQ

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

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

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

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

Обзор вклада ИТ

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

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

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

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

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

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

Дополнительные сведения см. в разделе Безопасность в Lokad.

Обзор временной линии

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

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

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

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

Первая загрузка данных: После утверждения спецификаций клиент загружает первый набор данных на серверы 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 У вас есть несколько сред?

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

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

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

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

1.11 Может ли клиент отказаться от выпуска?

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

Для ситуаций, когда выпуск может быть временно отложен, см. Управление выпусками 1.1.

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

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

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

Большинство наших клиентов получают преимущества от предложения “программное обеспечение + эксперт”, где команда ученых по цепочке поставок Lokad отвечает за внедрение и поддержку решения по цепочке поставок клиента. Эти ситуации известны как “цепочка поставок как услуга”. В этих условиях клиент регулярно взаимодействует с одним (или несколькими) учеными по цепочке поставок. Кроме того, большинство клиентов получают преимущества от еженедельного или ежемесячного руководящего комитета для обсуждения текущего состояния решения и любых желаемых изменений. 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-часовым простоем, но это кажется практически глупым в данном контексте.

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

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

Да, в пределах 500 мс, но с оговорками.

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

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

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

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

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

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 возникает, когда присутствует комбинация трех факторов.

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

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

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

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

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

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

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

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

См. Авторизация 3.6 и Журналирование и мониторинг 5.3 в нашей документации по Безопасности для получения дополнительной информации о “транзакциях” в решении Lokad.

2.12 Какова производительность при наличии одновременных пользователей в решении?

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

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

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

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

2.14 Осуществляется ли автомасштабирование вычислений и хранилища по мере необходимости?

Да. Платформа Lokad является многопользовательской. Благодаря многопользовательской системе мы выполняем масштабирование вычислительных ресурсов в большом масштабе с низкой задержкой. Это означает, что автомасштабирование вычислений, которое предоставляет Lokad, в разы быстрее, чем создание больших виртуальных машин (VM) у поставщика облачных вычислений. Автомасштабирование хранилища в основном выполняется с использованием свойств автомасштабирования постоянного хранилища ключ-значение, предоставляемого базовой платформой облачных вычислений (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), точке восстановления (RPO) и требованиям аварийных сценариев (как определено и согласовано с соответствующими клиентами)?

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается “решений”, стоит отметить, что квантитативная философия цепочки поставок (QSC) Lokad заключается в поиске наиболее финансово выгодного компромисса при возникновении проблемы. 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,…).

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

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

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

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

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

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

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

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

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

4.13 Могут ли компоненты GUI быть отделены от бэкэнда?

Да, компоненты GUI (в данном случае веб-интерфейсы) являются автономными. Это позволяет достичь большей доступности. Конечные пользователи могут получать доступ к панелям управления своей учетной записи 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?

N/A. Поскольку 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)?

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

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

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

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

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

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

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

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

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

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

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