Как стать автором
Обновить

Комментарии 22

Идея «многоквартирного дома» для пользователей очень хорошая — в плане устойчивости и стоимости ведения «хозяйства жкх». Хотелось бы в дальнейшем получить примеры экономии «жильцов» этого «дома» на сопровождении своих баз и на отсутствии проблем. Желательно в цифрах. Заранее спасибо.
Например здесь (используется продукт 1cFresh).
А вот про пример использования 1cFresh внутри большой организации (ДИТ Москвы) — новость «Переход на облачную ERP сэкономил Москве миллионы рублей», официальное письмо от ДИТ Москвы.
какие условия получения продукта 1cFresh для коммерческих организаций не занимающихся франчайзингом 1с? для собственных нужд, но интересует больше не сам продукт(его бери да купи), а поддержка и инструментарий как у Кнопки.
«А мы покупаем или продаём?» :)
Поддержку и инструментарий как у Кнопки — вы хотите получать или сами оказывать своим клиентам?
По поводу термина: Microsoft предлагает перевод «мультитенантность» или описательное «архитектура обслуживания одним экземпляром приложения нескольких развертываний».

Мне сначала термин «мультитенантность» показался неудачным, но на самом деле он оказывается лучшим вариантом: ведь, как сказано в начале статьи, «мультиарендность» и «множественное владение» неточны.
Для «песочниц» используете штатные возможности ОС изоляции (процессы/потоки) и/или собственные механизмы?
Используем собственные механизмы. В основном потому, что настройки, используемые в наших профилях безопасности — application-specific, и ОС про них ничего не знает.
половина из того что описано в примерах в русском языке называется греческим заимствованием синергия. (не грамар наци, да и вообще не русский, просто мешает пониманию, когда ты читаешь примеры, четко попадающие под уже известную абстракцию а тебе их называют новым неизвестным словом которое ты пытаешься понять а в итоге оказывается что тебе просто неправильно объясняли/неудачно подобрали примеры)
Синергия — это совсем другое понятие. Synergy и Multitenancy это даже не синонимы.
Да, спасибо, я в курсе. Мое недоумение было по поводу того что в статье объясняется Multitenancy на примерах синергии.
для слова multitenancy действительно нет хорошего перевода, приходится либо использовать англицизм «в лоб», либо использовать «мультиарендный» (потому что многоквартирный, многозадачный, многопользовательский, мультисервисный уже заняты); впрочем, я не знаю всех вариантов, с удовольствием бы услышал предложения
простите, о наболевшем

Мы начали формировать наше понимание multitenancy одновременно с тем, как начали проектировать подход к облачной (сервисной) модели работы «1С: Предприятия». Это было несколько лет назад.
А в вашем организационном понимании есть пункт о желательности Linux/Postgres для облачных (сервисных) моделей вместо Microsoft Windows/SQL? Потому что те ребята, которые меня консультировали, вообще не рекомендовали использовать Linux и Postgres, ссылаясь на проблемы с производительностью. Что это — реальная проблема или плохое информирование торговой сети? Боюсь даже заикаться про FreeBSD и официальную совместимость файлового backend'а с samba.

Т.н. «отраслевые» решения требуют аж двух аппаратных USB-ключей. Многие способны паковать гирлянды USB-ключей в корпуса с помощью специальных адаптеров, но это всё равно дико неудобно. Аппаратные USB-ключи с облачными продуктами сочетаются плохо, промышленная виртуализация вообще не любит USB, это блокирует автоматическое перемещение машин (контейнеров) между физическими хостами в случае отказа последних. Варианты типа AnywhereUSB — тоже точка отказа и та ещё заноза, ни о каком multitenancy речь не идёт.

Таких процессов десятки: создание новых областей данных («квартир»), обновление приложений, обновление нормативной информации, резервное копирование и т. д.
Ага, попробовал тут давеча через командную строку вызвать конфигуратор на выгрузку, не засвечивая пароль сервисной (привилегированной) учётной записи. Перепробовал с десяток способов использовать аргумент /@ <имя файла>, но всё без толку, не берёт пароль и всё. Плюнул, забил пароль открытым текстом. Либо я полный утюг, либо интерфейс командной строки Предприятия застрял в конце 90-х годов…

Облачно-сервисная модель предполагает мощный интерфейс командной строки и сетевой API (например, REST API). Чтобы не светить пароль в командной строке, современные утилиты дают возможность считать его через конвейер (pipe, file handle), либо хотя бы просто из файла.
А в вашем организационном понимании есть пункт о желательности Linux/Postgres для облачных (сервисных) моделей вместо Microsoft Windows/SQL?

Да, конечно. И не только пункт есть, но и на практике применяем и сами («Для собственных нужд «1С» также использует открытую СУБД, PostgreSQL, которая (наряду с MS SQL) используется в облачном сервисе 1С:Fresh, функционирующем с 2012 года.»), и наши партнеры.

Потому что те ребята, которые меня консультировали, вообще не рекомендовали использовать Linux и Postgres, ссылаясь на проблемы с производительностью. Что это — реальная проблема или плохое информирование торговой сети?

Может быть — нежелание «ребят» учиться новому?

Аппаратные USB-ключи с облачными продуктами сочетаются плохо

Согласен. В этом случае лучше использовать программные лицензии.

Перепробовал с десяток способов использовать аргумент /@ <имя файла>, но всё без толку, не берёт пароль и всё.

Пробовали каждый параметр в файле размещать на новой строке?
во-первых, благодарю за ответ о наболевшем, я тогда ещё поделюсь мыслями с Вашего позволения…

Может быть — нежелание «ребят» учиться новому?
Может, и так. Но если ваш департамент по работе с торговой сетью проводит регулярное анкетирование или учебную аттестацию, добавьте вопросы по теме выбора платформ. Сможете увидеть реальную картину, и, если она отличается от желаемой, проведёте кампанию по информированию торговых партнёров. Даю готовые примеры.

примеры вопросов
1. На какой платформе достигается лучшая производительность при работе Предприятия?
A. Microsoft Windows Server и СУБД SQL Server
B. Поддерживаемый сервер Linux и СУБД MySQL
C. Поддерживаемый сервер Linux и СУБД PostgreSQL
D. Поддерживаемый сервер Linux и СУБД Oracle
E. Любой из вариантов A или B.
F. Любой из вариантов A или C.
G. Любой из вариантов A или D.

2. Какую платформу Вы порекомендуете заказчику, если не стоит вопрос с лицензиями?
A. Microsoft Windows Server
B. Microsoft Windows Professional
D. Сервер Linux с платной поддержкой
D. Cервер Linux с бесплатной (community) поддержкой
E. Ничего из вышеперечисленного

Примечание: варианты содержат distractor'ы, т.е. неверные ответы.

Аппаратные USB-ключи с облачными продуктами сочетаются плохо.
В этом случае лучше использовать программные лицензии.

Так уж вышло, что моему проекту понадобилось т.н. отраслевое решение (коробочная конфигурация). Отличная идея, между прочим, и неплохая реализация, но никаких вариантов использования отраслевых конфигураций без аппаратных «катрановских» ключей по моим данным не существует. Мне пришлось пропиливать двухслойный пирог из FreeBSD jail и VirtualBox, это сущий ад… Были планы даже изложить это здесь или на ГТ, но пока времени нет.

А теперь давайте на секунду представим, что я решил стать оператором облачного сервиса 1С.

фантазии облачные, v1.0
1. Кто мой заказчик? Я не создаю ИТ-дочку под крылом крупного холдинга, поэтому мой заказчик — малый или средний бизнес, дай бог.

2. Что я могу предложить? Полный комплект Предприятия и доработку каждому заказчику? Ну уж нет, откуда такие ресурсы… Скорее, я предложу выбор из стандартных продуктов, готовых отраслевых конфигураций по каталогу и отработаю взаимодействие с разработчиками каждой. Портфель можно было бы развивать постепенно, начав с трёх-четырёх продуктов.

3. Чем я могу привлечь заказчиков? Отсутствием головной боли с эксплуатацией, простотой доступа через веб-приложения и с любых устройств, гарантированной доступностью сервисов. Придётся как-то помогать заказчикам консультациями по резервированию Интернет-доступа, но как побороть аппаратные ключи — вот вопрос. Если хотя бы пару раз отвалится выделенный сервер с аппаратными ключами, моему бизнесу крышка.

4. Что с безопасностью данных? Можно начать со статических фильтров и VPN, но по-хорошему нужна глубокая интеграция с CASB-решениями типа Imperva SkyFence. CASB отъедают рынок у MDM, поэтому на MDM можно не рассчитывать.

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

6. Наконец, как полностью автоматизировать генерацию серверов и конфигураций? Необходимо полностью перейти на Linux-платформу, использовать виртуализацию и скриптовые сервисы типа REST API. Но помимо командной строки «привет из 90-х» ничего не предлагается...


bottom line: 1C:Fresh — это отлично, но если распространять франшизу дальше, то методы работы с операторами и брокерами облачного доступа существенно отличаются от привычных моделей торговой сети.
Большое спасибо за подробную информацию, познавательно.

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

1C:Fresh — это отлично, но если распространять франшизу дальше, то методы работы с операторами и брокерами облачного доступа существенно отличаются от привычных моделей торговой сети.

Можете развить? В какую сторону отличаются, в какую сторону рекомендуете двигаться.
У вас были проблемы с конкретным отраслевым решением?

Да, но об этом лучше в личной переписке.

Можете развить? В какую сторону отличаются, в какую сторону рекомендуете двигаться.
DISCLAIMER: я не BDM:)

диванная аналитика
Операторы облачных услуг — прежде всего владельцы инфраструктуры и автоматизированных технологических процессов. Сфера деятельности весьма близка к телекому (и традиционному веб-хостингу). У операторов весьма прокачанные службы эксплуатации. Операторы фокусируются на стандартизации и автоматизации, выручка генерируется массовой продажей типовых решений по модели подписки (аренды), но без глубокого погружения в нужды и проблемы каждого заказчика. Оператор услуг отвечает, прежде всего, по всевозможным SLA, за несоблюдение которых идут штрафы. Важен анализ утилизации (использования) инфраструктуры, планирование и развитие. Если продукт ориентирован на бизнес, есть отдел продаж и сейлы, работающие с корпоративными заказчиками. Если продукт потребительский, продажи генерирует маркетинг в разных формах. Но, повторяю, выручка генерируется по рентной модели: лучше каждый год получать по 50р, чем один раз продать лицензию за 100р и потом продлевать поддержку за 30р.

Ваших франчайзи Вы знаете лучше меня. Полагаю, у них нет ни инфраструктуры, ни серьёзных групп эксплуатации, ни SLA, только размытые обязательства по ответу на запросы в рамках программ техподдержки. Выручка идёт от продажи продуктов и профессиональных услуг по их внедрению, но по принципу один раз 100р и потом каждый год 30р. Соответственно, в штате есть специалисты по внедрению и платформам, но от Windows/Linux/SQL они абстрагируются. Отделы продаж у франчайзи, на мой взгляд, единственное похожее звено на операторские отделы по работе с бизнесом. Про маркетинг ничего определённого сказать не могу.

Мне кажется, что у крупных операторов есть мощные инфраструктурные и маркетинговые ресурсы, но им неинтересно заниматься внедрением 1С, это семечки. Обычным же франчайзи очень тяжело стать операторами, им проще взять инфраструктуру в аренду, занимаясь тем же самым, что и раньше. Но если 1С нужно нарастить долю рынка, возможно, имеет смысл пойти к крупным игрокам и продавать эту идею им, готовясь значительную часть работы взять на себя. Придётся либо закрыться на коробочных продуктах, либо как-то восполнять подгонку под требования заказчиков. В любом случае нужно будет контролировать удовлетворённость конечных закзачиков всей цепочкой в целом. Продукт наверняка придётся допиливать (я уже обозначал, где именно, и про функции CASB не шутил, хотя это относительно новая ниша даже в мировом масштабе).

Вот вам и синергия: сочетание возможностей операторов инфраструктуры и желания франчайзи работать с заказчиками индивидуально.

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

ОК! Пишите в личку.

И спасибо за развернутый ответ.
Перепробовал с десяток способов использовать аргумент /@ <имя файла>
Пробовали каждый параметр в файле размещать на новой строке?


да, в том числе так:

подробности
"C:\Program Files\1Cv8\common\1cestart.exe" CONFIG /@ E:\1C\cred.txt /F E:\1C\ENTERPRISE /DumpIB \\server\backup\share


файл E:\1C\cred.txt из двух строк:
/N sysuser
/P very-secret-password


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

Linux и Postgres поддерживаются для работы. Попробуйте обратиться за разъяснением к консультантам, которые дали Вам такую рекомендацию.

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

Вопросы по командной строке, в которой критично «не светить пароль», не совсем ясны. Вроде бы любая работа с серверами из командной строки должна происходить только из trusted окружения. Я ошибаюсь?
Речь идёт о запланированном по расписанию задании. Промышленный сервер, хостящий облачные сервисы, обслуживается не одним человеком, а группой с чётко поставленными ролями, и далеко не всем полагается видеть пароли. Имя процесса и аргументы командной строки слишком легко подсмотреть стандартными системными утилитами, обладая минимальными правами юзера, поэтому современный софт принципиально избегает задания пароля в командной строке. Да и компрометация (взлом) сервера — явление сейчас настолько обыденное, что понятие trusted окружения очень условно и размыто.

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