Файл: Пользователь 8, он же UserH.docx

• 
  Организовать контроль производительности и статистики сообщений об ошибках
  
  • 
    подсказать бизнесу поставить бизнес-задачи по контролю производительности: 
    http://gilev.ru/apdex-teoriya
    
  • 
    всегда собирать статистику ошибок 1C технологическим журналом и анализировать её, например, http://gilev.ru/status
    
  • 
    инструменты http://gilev.ru/online облегчают многие задачи;
    
• 
  Не забивать сервер всем подряд, пока он не выдержит. Следить, чтобы под каждую новую задачу бизнес выделял новую инфраструктуру
  
• 
  Размер данных и количество пользователей не должны расти бесконтрольно, рано или поздно не выдержит любой сервер. Необходимо распределять нагрузку по доступным мощностям;
  
• 
  При небольшом количестве пользователей и данных – проблему производительности как правило ДЕШЕВЛЕ решить наращиванием оборудования, а не кодом;
  
• 
  Не экономить на процессоре, нужен баланс максимальной частоты и количества ядер, не забывать включать максимальную производительность:
  
  • 
    в энергоснабжении http://gilev.ru/systemperfomance
    
  • 
    в биосе сервера http://gilev.ru/bioshp
    
  • 
    в биосе виртуалки (если есть).
    
• 
  Гипертрединг надо оценивать по ситуации, но в виртуалках может увеличить стоимость владения: http://gilev.ru/hyper-threading
  
• 
  При развертывании нового сервера по возможности избегать виртуалок.
  Но если избежать не удалось – каков план действий?  http://gilev.ru/virtual
  
• 
  При небольшом количестве пользователей совмещать роли сервера 1С и сервера СУБД, чтобы использовать обмен напрямую через память Shared Memory: http://gilev.ru/sqland1c
  
• 
  При подборе диска не ориентируйте только на iops http://gilev.ru/iops, старайтесь минимизировать время отклика и максимизировать линейную скорость записи, глубину очередей
  
• 
  Необходимо все интенсивно используемые файлы перенести на NVMe SSD, подробнее http://gilev.ru/linkdir/#nvme (особенно для tempdb и журнала регистрации 1C, если он в «новом формате» SQLite);
  
• 
  В редких случаях при миграции на старшую версию СУБД бывает необходимо включить «старый» алгоритм оптимизатора запроса флагами трассировки http://gilev.ru/legacy_query_optimizer
  
• 
  Для терминального сервера Windows Server 2012 и более новых версий – бывает потребность выключить DFSS: http://gilev.ru/dfss
  
• 
  Обеспечить возможность разработчикам писать код именно в той среде, в которой потом этот код будет эксплуатироваться, но при этом держать выделенную изолированную среду от продуктивных баз
  
• 
  Организовать контроль загруженности оборудования и типов ожиданий на СУБД:
  
  • 
    При оптимизации оборудования и настроек не делайте более одного изменения за раз, чтобы можно было точно оценить вклад каждого изменения
    
  • 
    Некоторые счетчики загруженности оборудования можно посмотреть в инструкции к сервису анализа оборудования, а также интерпретация счетчиков в виртуальном сервере
    
  • 
    при возникновении ожиданий или значений счетчиков, значительно превышающих пороги устранять узкие места или уменьшать нагрузку, в том числе уменьшением объема данных в таблицах
    
• 
  При возникновении массивных блокировок на чтение – проанализировать использование версионирования http://gilev.ru/snapshot1c
  
• 
  При ожиданиях pagelatch_xx проанализируйте добавление файлов tempdb: http://gilev.ru/pagelatch_xx
  
• 
  Включаем быструю инициализацию файлов http://gilev.ru/se_manage_volume_name
  
• 
  Разносим нагрузку по дискам, если возникают ожидания pageiolatch, а также анализируем отсутствующие индексы, например с помощью сервиса http://gilev.ru/sqlsize
  
• 
  Текущую картину ожиданий видно в Мониторе Активности СУБД, а блокировки и транзакции в консоли сервера 1С – в сеансах базы, просто так делать «потому что соседу помогло» не стОит, можно «устать», не добравшись до действий, которые окажут наибольшую пользу
  
• 
  отслеживать историю регламентных заданий на СУБД по обеспечению резервного копирования, обновления индексов и статистики; бывают нюансы: http://gilev.ru/trace2371
  
• 
  помогать программисту обнаруживать проблемные запросы с помощью инструмента анализа долгих запросов QueryTJ http://gilev.ru/querytj, 3 запроса в месяц, выявленных нашим инструментом и затем ускоренных – позволят говорить о сохранении производительности на высоком уровне;
  
• 
  автоматизируйте анализ рутинных вопросов, чтобы на события падения сервера, и другие важные события Вам оперативно поступали оповещения.
  
• 
  Как быстро понять, что пришла пора апгрейдить сервера: http://gilev.ru/upgrade
  
• 
  Про диски для 1С (статья плюс сборник дополнительных линков): http://gilev.ru/ssd1c
  
• 
  Выясняем нормативы потерь при сбоях: http://gilev.ru/rpo и http://gilev.ru/rto
  
• 
  Параметры BIOS, влияющие на производительность: http://gilev.ru/?s=bios
  
• 
  Про динамическое обновление 1С: http://gilev.ru/dynamicupdate1c
  
• 
  Частота и производительность RAM зависят от того, как она воткнута: http://gilev.ru/ram
  
• 
  Про терминальный сервер «для 1С»: http://gilev.ru/rdponly
  
• 
  Общесистемные и групповые замедления в 1С, причины: http://gilev.ru/groupslowdown
  
• 
  Неожиданное поведение платформы 1С в динамических списках: http://gilev.ru/hiddenfields
  
• 
  Приоритет ipv4 над ipv6: http://gilev.ru/2net
  
• 
  Пример методики выявления проблем блокировок в 1С: http://gilev.ru/timeoutlock
  
• 
  Выявление ошибок нехватки прав службы сервера 1С: http://gilev.info/2019/02/1.html
  
• 
  Мониторить происходящее в консоли сервера 1С можно с помощью конфигурации Session Monitor: https://infostart.ru/public/1329606/
  
• 
  Одна тонкость при обновлении сервера 1С: http://gilev.ru/when_updating_the_1c/
  
• 
  Как установить несколько служб 1С: http://gilev.ru/multiple1cservers/
  
• 
  Как отправлять данные в сервисы Gilev.ru через HTTPS в условиях санкционных ограничений:
  http://gilev.info/2022/06/gilevru-https.html
  

Check list администратора 1С

Ежедневно:

• 
  проверять актуальность бэкапов (как копии на локальных ресурсах, так и копии на сетевых);
  
• 
  проверять логи ОС на серверах на предмет ошибок (на windows – это application log, security log и system log);
  вариант автоматизации парсинга логов: связка ELK (ElasticSearch, LogStash, Kibana) или аналог:OpenSearch+Filebeat/Winlogbeat
  
• 
  проверять логи СУБД на предмет ошибок;
  
• 
  проверять логи веб-сервера на предмет ошибок;
  
• 
  убедиться, что работает мониторинг серверных ресурсов (потребление памяти, процессора, свободное место на дисках, температуры проце ссоров и дисков);
  
• 
  проверить логи ЖР 1С продуктивных баз 1С на предмет ошибок;
  
• 
  проверить доступность всех продуктивных веб-сервисов;
  

Ежедневно, при наличии учётки сервисов gilev.ru:

• 
  проверить статистику ошибок и блокировок в сервисе Status http://gilev.ru/status
  
• 
  проверить статистику долгих запросов в сервисе QueryTJ http://gilev.ru/querytj
  
• 
  проверить состояние СУБД (состояние статистик, фрагментация, размеры таблиц) в сервисе SQLSize http://gilev.ru/sqlsize
  

Постоянный мониторинг (с высокой частотой, каждые 1-15 минут):

• 
  мониторинг серверных ресурсов (потребление памяти, процессора, свободное место на дисках, время обслуживания дисковых операций, температуры процессоров и дисков);
  
• 
  проверить доступность всех продуктивных веб-сервисов;
  

Еженедельно:

• 
  проверять развёртывание баз из бэкапов продуктивных баз на тестовых серверах;
  

Ежемесячно:

• 
  тренировка по отработке отказов системных ресурсов (проводится на тестовых серверах);
  
• 
  при возможности: контроль SMART на дисках продуктивных серверов, контроль ресурса на SSD продуктивных серверов;
  
• 
  проверка антивирусом (предварительно обновлённым до актуального состояния сигнатур) папок профилей пользователей на серверах;