Поддержка корпоративных клиентов

1. Поддержка корпоративных клиентов

Дата и место проведения мероприятия
Поддержка
корпоративных клиентов
Докладчик
Должность

2. Особенности

Автоматизация в крупной компании
Бизнес-критичный функционал
Доверие к системе и стоимость эксплуатации
Масштабирование
Развитие интеграций
Надежность
Доступность
Работа с большими объемами данных
2

3. Партнер на корпоративном рынке

Роль партнера
Продать
Поддержать клиента
Доработать решение
Помочь подобрать оборудование
Показать, что система может работать с определенными требованиями
Объем функционала
Производительность
Стоимость лицензий и поддержки
▪ Выбор ОС и СУБД
▪ Конфигурация системы
Но разработанной системы в начале проекта нет
▪ Нужно показать до окончательного выбора клиента
3

4. Планирование

Составление плана проекта
Выписываем задачи в порядке важности и срочности
Для каждой из задач оцениваем объем работ
Для всех работ оцениваем план, к которому стремимся
Обсуждаем сроки с клиентом, договариваемся
Примерный план
Оценка возможностей типового продукта, оценка объема
кастомизаций
Закупка оборудования
Разработка кастомизаций
Контроль качества доработок, контроль стоимости
Внедрение, промышленная эксплуатация
4

5. Не нужно что-то долго разрабатывать

Предварительная оценка возможностей системы
«Демонстрационная база конфигурации «1С:ERP. Управление предприятием 2"
версии 2.4.2.144»
PostgreSQL 10.5-24.1С
Упрощение и улучшение формируемого плана запроса
Более точное вычисление сортировок в запросах
Повышена производительность выполнения группировок
Ускорено выполнение запросов при чтении требуемых полей из индексов
Корпоративный инструментальный пакет версии 2.1.3.
Центр Администрирования
▪ Установка платформы
▪ Сбор журналов
▪ Запуск Агентов Тест Центра
Тест Центр
▪ Запуск нагрузочного теста
Центр Управления Производительностью
▪ Анализ собранных данных
5

6. Обязательно нужно говорить с клиентом

Работа с клиентом
Формализация процессов у клиента
Сценарии работы в ИС
Число пользователей
Роли пользователей
Операции пользователей
География
Требования к доступности и надежности
Интеграции
6

7. Как купить джинсы без примерки, можно и не влезть…

Заказ оборудования
Методика на kb.1c.ru: «Оценка требований к оборудованию
на нагрузочном тесте»
По сути:
Моделирование сценария, наиболее приближенного к работе
в продуктиве
Оценка наличия проблем производительности в программной части
▪ Оборудование загружено меньше, чем когда проблем нет
Оценка загруженности оборудования
Оценка, объема требуемых ресурсов, чтобы оборудование
справлялось
7

8. Настроить как в продуктиве

Настройка стендов
Статья в технологической базе знаний
«Установка Платформы «1С:Предприятие» в ОС Linux»
«Настройки PostgreSQL для работы с «1С:Предприятие»»
«Check-list по настройке рабочих серверов в продукционной зоне»
Контроль ресурсов с помощью Центра Контроля Качества
Помощь в настройке серверов
Контроль пакетов обновлений ОС
Оценка загруженности оборудования
8

9. Ничего не забыли?

Настройка стендов
Настроили ОС, СУБД, кластер 1С по методикам с kb.1c.ru
Развернули ИБ
Посчитали индекс ППД
Зарезервировали место под журналы регистрации
Настроили мониторинг
Настроили экспорт собираемых данных
Бэкапы
9

10. Мониторинг – это не только какие-то журналы платформы

Настройка мониторинга
Технологические журналы
Счетчики ОС по загруженности оборудования
Журналы СУБД
Журналы веб-серверов
Агент КИП для
Контроля доступности сервера (машины)
Контроля настроек и доступности рабочего сервера
Учет дампов аварийных завершений процессов
10

11. Нагрузочный тест как вождение в городе перед получением прав

Подготовка и проведение тестов
Наполнение базы по объему документов, справочников, …
Распределение данных, эквивалентное боевому
Чем ближе распределения, тем актуальнее статистика и ближе планы
Реалистичный сценарий нагрузочного тестирования
Важно не забыть, что будут интеграции с другими системами
Минимальная длительность выполнения – все операции точно
должны выполниться
Идеальный вариант – 4 часа
Ключевая цель:
Полный объем технологических данных от теста
Как бы плохо всё не закончилось, нужны данные, с которыми потом
можно будет работать
11

12. Стратегии нагрузочных тестов

Стратегия 1:
1. Провели тест и зафиксировали начальное состояние
2. Сравнили с требованиями
3. Если показатели не удовлетворяют требованиям:
a)
Проанализировали собранные данные
b)
Выполнили оптимизацию
c)
Повторили нагрузочный тест
d)
Вернулись к п.2
4. Зафиксировали результат
12

13. Стратегии нагрузочных тестов

Стратегия 2:
1.
Провели тест и зафиксировали начальное состояние
2.
Зафиксировали требования
3.
Выполнили разработку
4.
Повторили нагрузочный тест
5.
Сравнили с требованиями
6.
Если показатели не удовлетворяют требованиям:
7.
a)
Проанализировали собранные данные
b)
Выполнили оптимизацию
c)
Повторили нагрузочный тест
d)
Вернулись к п.5
Зафиксировали результат
13

14. Общее в нагрузочных тестах

Стратегии нагрузочных тестов
В двух стратегиях есть:
1.
Собранные полные данные от первого теста
2.
Собранные полные данные от финального успешного теста
3.
Требования существуют
4.
Финальный результат удовлетворяет требованиям
Нагрузочный тест ради теста не нужен. Можно не терять время и не тратить деньги,
если ничего не планируется потом, т.к. изменений в рабочей системе не будет.
14

15. По одному изменению зараз

Выбор СУБД, ОС
Когда есть качественно собранные полные данные от теста,
результаты можно сравнивать, изменяя что-то одного в тесте
Можно изменить СУБД, провести повторный тест, сравнить
производительность
Можно изменить конфигурацию системы, ОС, железо, …
Но всегда что-то одно на один тест.
Иначе не понятно, что именно изменило результаты
(производительность, параллельность, …).
15

16. Характеристики продукта

Ведение разработки
Функциональность
Качество
По сути продукт обладает характеристиками:
Зачем он нужен? (Например, по телефону можно звонить. Если нельзя, то
телефон не нужен.)
Функциональность
Сколько стоит использование? (Если телефон стоит как самолет, то может быть
есть другой телефон дешевле. Или можно не звонить, а писать…)
Качество
Чем выше качество, тем меньше стоимость использования для клиента
Идеальный вариант: работает «из коробки», не требует внимания совсем
длительное время
Если не заниматься качеством, то стоимость может оказаться выше, чем
плюсы от владения продуктом. Стоимость всегда должна быть меньше
приносимой пользы.
16

17. Как не сломать продуктив одним исправлением

Контроль результатов и запуск в продуктиве
Система решает поставленные задачи
Система соответствует определенным требованиям
Т.е. стоимость ее использования меньше выбранной границы
Если доработка ещё ведется:
Объединять задачи в версии
Проводить нагрузочное тестирование версий перед обновлением в
продуктиве
▪ Чтобы из-за ошибки стоимость не стала выше допустимой границы
▪ Если будут ошибки, решать, исправлять их или обновляться
Обновляться в рабочей системе
17

18. Помощь и поддержка

Поддержка КОРП
В процессе эксплуатации могут возникать вопросы и проблемы
Процессы КОРП поддержки описаны на сайте
https://consulting.1c.ru/
Услуга партнера – клиенту.
Цель: качественная работа системы клиента.
Фирма 1С – «страхует» партнера (в интересах клиента), помогает
решить:
Технические проблемы платформы и инструментов платформы
Где не хватает экспертизы
18

19. Обработка сбора аналитических данных

Если возникли непредвиденные проблемы
производительности:
Статья в технологической базе знаний: «Сбор технологической
информации для расследования проблем производительности
и работоспособности с помощью ЦУП с использованием внешней
обработки»
Клиенту не нужно ничего покупать
Партнер сам анализирует, используя Центр Управления
Производительностью
19

20. Поддержка корпоративных клиентов

Дата и место проведения мероприятия
Поддержка
корпоративных клиентов
Спасибо за внимание!
Докладчик
Должность