Хочу сказать, что это за 10 заповедей, откуда взялись. Это – не пересказ ИТС, не пересказ «Настольной книги эксперта» или «Настольной книги эксплуататора 1С». Это –опыт нашей компании, который взят из нескольких источников.
-
Во-первых, мы – облачные провайдеры 1С. Там свои приколы, костыли и проблемы. Когда у вас одна база и тысяча пользователей – это одна проблема, когда у вас тысяча баз по два пользователя – это совсем другие проблемы, это вообще другой мир.
-
Второе – мы являемся партнерами по РКЛ – расширенной клиентской лицензии. Те счастливчики, которые обладают КОРП-лицензиями платформы, могут заключить с нами договор РКЛ, и мы год будем их сопровождать по ошибкам платформы и по всяким разным непонятностям. Из этого и складывается наш опыт.
-
Плюс мы часто проводим аудиты разных крупных информационных систем.
Я собрал в этом докладе не столько ошибки, сколько советы – что сделать, чтобы стало намного лучше. Я назвал эти советы «10 заповедей», потому что их, с одной стороны, как и любые заповеди, легко исполнить, с другой стороны, почти все их нарушают.
Раздели зоны
Первая заповедь – разделяйте зоны.
Кого не спросишь – конечно, рабочая зона разделена на зоны разработки и тестирования. Но по факту, в 95% случаев это вообще не так.
Проводя аудит, мы заходим на рабочую зону СУБД, а там 100 баз. Из них рабочие – две. Что там остальные 98 баз делают – не понятно.
Такой же “бардак” на серверах 1С. К чему это в итоге приведет? В итоге, когда-то кто-то (причем, обычно опытный разработчик) запустит на тестовой базе такое, что у вас ляжет вся инфраструктура. Он вам сделает декартово произведение большой таблицы, и всё «умрет».
Молодой так не сделает – навряд ли, просто из-за того что сомневается в правильности своих решений. А вот опытный – казалось бы, ну он-то понимает – он точно сделает, так как уверен.
Разделяйте зоны – не только на уровне бумаг и регламентов. Разделяйте зоны технически. До рабочих серверов СУБД не должно быть сетевого доступа с любых серверов 1С, кроме рабочих. И наоборот, рабочие сервера 1С не должны иметь доступа к тестовым СУБД.
Разделите. Иначе будет большая беда.
Да, потом начинается: «Ой, нам ресурсов не дают, сервера не выделяют». Бюджетирование вашей системы – это другой вопрос. Решайте. Ресурсы должны дать. Такого не бывает, чтобы не разделить зоны в крупной информационной системе.
Мы сейчас говорим о крупной информационной системе, где больше нескольких сотен пользователей.
Дублируй системы
Следующий момент – дублируйте.
Многие на конференцию прилетели на самолете. Наверняка же вы, когда садитесь в самолет, уверены, что там системы задублированы – один штурвал откажет, есть второй. Один пилот умрет – есть второй. Некоторые особо критичные системы имеют трёхкратный, и даже четырёхкратный дубляж.
И тут мы почти всегда сталкиваемся с очень интересным моментом. Дублировать физические сервера (железки) никто не против. Реально покупают два сервера. Или дублировать виртуальности правильно – на разных хостах, не на одном хосте две виртуалки держать и называть это дубляжом – тоже никто не против, это тоже руками можно пощупать. Дублировать СУБД – делать зеркала, реплики и т.д. – вроде тоже научились. Даже научились делать два центральных сервера в кластере 1С. И тоже все не против.
Но как только мы говорим: «А где второй набор клиентских лицензий?» Все сразу: «Стоп, зачем второй набор лицензий? Мы что, еще деньги должны платить за это?»
А как вы себе представляете? У вас умрет сервер лицензирования, и вся ваша мегазадублированная система встанет колом. Все будет работать, только не для пользователей, а для системных администраторов. Пользователи будут звонить с жалобами: «Не могу в 1С зайти». А сисадмины будут им отвечать: «У меня на серверах все хорошо». Конечно, там все хорошо, там никого нет, система никого не пускает.
В обязательном порядке дублируйте клиентские лицензии.
Не нужно только хитрить, не нужно, когда у вас тысяча пользователей, покупать две лицензии на 500 пользователей, класть их на два разных сервера и говорить – у нас задублировано. Нет, у вас умрет половина системы. Да, не вся, слава Богу, но половина умрет. Это не дубляж. У самолета отвалится одно крыло – вам сильно легко будет лететь? Так же и там. Как вы будете определять, кто станет жертвой, а кто нет? Кого отключить от 1С, а кого – пустить? Бизнес такое не поймет.
Поэтому дублируйте все системы, с которыми работает 1С. В крупных системах не бывает лишних дубляжей.
Примири админов и одинэсников
Следующий момент. К кому не придешь – все говорят: «у нас админы и 1С-ники – лучшие друзья, в бар каждую пятницу».
К сожалению, не верю. Два дня назад проводил скайп с заказчиком, там админы с 1С-никами поссорились прямо во время совещания. И так, к сожалению, почти всегда.
Если у вас реально мир, труд, дружба, жвачка – молодцы. Но если нет – это огромная проблема.
Когда случится авария, вместо того чтобы ее совместно решать, они начнут сваливать друг на друга. И там начнется гонка – кто быстрее позвонит своему начальнику и скажет: «Это не мы, это они». Такое «сваливание вины» вместо совместного поиска решения проблемы приводит к большим проблемам в больших компаниях, на больших инсталляциях.
Повернись лицом к DevOps
Как примирить админов и одинэсников? Нет ничего лучше, чем общие задачи. Подружитесь с DevOps.
Только не нужно сейчас путать DevOps с автотестами. Автотесты и все, что вокруг тестов – это маленькая часть DevOps. Это не основная ее часть.
DevOps – это совместная работа ИТ-подразделения с разработчиками над инфраструктурной системой. Сюда можно вложить все, что угодно.
Начните с чего-то малого, не нужно сразу бросаться в дебри. Хотя бы сделайте так, чтобы ошибки журнала регистрации 1С раз в 10 минут собирались и отправлялись на почту. Чтобы к этой задаче подключить админов, попросите их сделать, чтобы сервер 1С мог авторизоваться на почте по IP и отправлять письма без пароля. Для начала – хотя бы что-то.
Напишите, наконец, веб-интерфейс. Или возьмите конфигурацию «Управление серверами 1С», которую фирма 1С уже для вас сделала. Дайте там разработчикам права до сессий их баз в консоли сервера 1С.
Проблема же в том, что если вы дадите доступ в консоль сервера 1С, то разработчик может и удалить чужую базу. Ты там или админ, или никто. Там нет прав. Дайте им права, пусть админы скрипты напишут через remote administration service (RAS-RAC). Или пусть выдадут программисту 1С какую-то небольшую веб-форму, где он выбирает базу данных, выбирает действие, что с ней сделать, видит активные сессии, убивает их и т.д. Это – первое.
Второе – DevOps нужен, чтобы убрать рутину. Рутины много и у тех, и у других. И у админов, и у 1С-ников. Рассматривайте DevOps с этой точки зрения. Это – не волшебная пилюля. Если вы внедрили DevOps – не значит, что завтра все само будет работать. Даже если сейчас оно само работает, завтра оно сломается. Даже если оно не сломается, у вас поменяются условия, при которых оно должно работать, и вам придется это все переписать.
DevOps – отличная вещь, чтобы помирить 1С-ников и админов. Тогда они с любой аварией будут разбираться вместе. Иначе будет борьба – кто кому позвонит.
Проводи учения
Все это имеет смысл, только если вы проводите учения.
Я вам гарантирую – если вы еще никогда свою систему не переключали на резерв, она не переключится. Как минимум, в то время, в которое вы думали, что она переключится.
Возникнет миллион проблем: «Ой, там адрес другой в скрипте». «Ой, у нас маршруты сети не прокинуты» и т.д.
В обязательном порядке – обязательно переключение между двумя мастерами, что бы это ни было – СУБД, сервера 1С или что-то еще – должно происходить периодически.
Учения должны быть. Либо вы в процессе работы раз в месяц/квартал обязательно переключаетесь. Либо вы проводите регулярные учения.
Расскажу наш опыт – карантин, конец марта 2020 года. Начальство принимает решение всех отправить на удаленку. Казалось бы, чего сложного? Терминальный сервер, VPN – поехали.
Первый раз мы ушли на удаленку на один день – решили провести учения на живую. По итогам этих учений стало очевидно, что канал интернета не выдерживает даже 100 сотрудников, а на терминальный сервер надо пустить 300. Как только сотрудников становится больше 100, у них начинаются тормоза, а они же еще привыкли дистрибутивы копировать гигабайтные себе на компьютер и т.д. Им все стало неудобно.
Но что еще показали учения? Когда мы отпустили сотрудников на удаленку всего на один день, 80% сотрудников отложили задачи на завтра. И мы даже не знали, что есть проблемы.
Учения прошли, мы составили план работ, и через неделю, исправив то, что мы узнали, мы отправили сотрудников на удаленку на три дня. Причем, со среды, чтобы эти три дня по факту превратились в пять - среда, четверг, пятница, суббота, воскресенье. И если сотрудник что-то не сможет сделать в среду, ему все равно пришлось бы это сделать до понедельника, он не мог бы это отложить.
Вылезло еще в три раза больше проблем. Оказалось, у кого-то куда-то нет доступа, кому-то так вообще работать неудобно, у половины сотрудников вообще нормального WiFi дома нет – им потом админы по домам провода развозили, чтобы у них телефония заработала, иначе она «квакает».
В этой элементарной задаче – организовать для всей фирмы к инфраструктуре удаленный доступ, которого никогда не было – нам понадобилось два учения.
Если бы мы просто переключились первого апреля на карантин, мы, скорее всего, вообще ничего не смогли бы сделать. Потому что бизнес-центр был закрыт, туда никого не пускали, мы бы не смогли подкорректировать свою инфраструктуру.
Поэтому учения крайне важны, и в них должны участвовать максимальное количество пользователей и сервисов.
Более того, по итогам учений у вас должны быть написаны конкретные, но короткие инструкции как для ит-подразделений так и для пользователей.
Помимо скриптов, которые делают это переключение, вы должны понимать, что там происходит в этих скриптах. И если на каком-то этапе что-то пошло не так, что с этим делать.
Научись читать техжурнал 1С
Следующий крайне важный момент – технологический журнал платформы 1С не должен быть для вас китайской грамотой. Учитесь его читать, как Нео – матрицу.
Не надо, опять же, сейчас включать полный техжурнал и читать гигабайты годами. Не надо.
Начните с малого. Начните с конкретной задачи. У вас есть таймауты ожидания на блокировках? А на какой базе? А у какого пользователя? А на какой строке модуля это возникло? А кто виновник? А как вычислить, что делал виновник?
Вам этой задачи хватит на неделю развлечений. Зато вы научитесь. Разобрали таймауты – научитесь разбирать длительные операции. Они у вас вообще есть? У вас пользователи в принципе ждут какую-нибудь операцию больше 30 секунд?
Вы удивитесь тому, что вы там увидите. У вас пользователи такие поиски по динамическим спискам задают… Ух! СУБД зависает по три минуты на LIKE-операциях. Или настраивают в списке кучу сортировок и группировок и ожидают часами, используя динамический список как отчёт, при этом “нагибая” всю систему.
Вот вам вторая задачка. Это – обязательно нужно проверить. Если недавно переустанавливали сервер 1С и пытались что-нибудь с правами делать, вы удивитесь, сколько гигабайт техжурнала у вас соберет ошибка «Отказано в доступе к файлу 1cv8conn.pfl». У вас будут миллионы записей, потому что наверняка забыли дать права на эту папку.
Читайте техжурнал. Настраивайте и читайте. Это черный ящик нашего самолета.
Пользователей нужно слушать, но они – субъективны. Кого-то в самолете тошнит, но самолет же от этого не плохой – он все равно летит и все системы работают штатно и быстро. И с тошнотой, наверное, тоже можно что-то сделать – например, можно дать таблетку.
Но объективный показатель – это только техжурнал. И не кидайтесь сразу собирать события СУБД, соберите события близко к пользователю – CALL, SDBL, TTIMEOUT. Начните с этого.
Обновляй платформу
Следующий момент – обязательно обновляйте платформу.
Я сейчас не призываю переходить на последние релизы, не нужно. Но и сидеть на 8.3.10 сейчас – это прямо кощунство. Если не хотите обновлять, вы хотя бы обязаны знать, что там в новых релизах. Читайте файл обновления.
В коде, написанном на современных платформах, не должно быть таких артефактов, как вызов HTTP-сервисов через Новый COMОбъект("MSWinsock.Winsock"). Еще в 2014 году в 8.3.5 фирма 1С сделала HTTP-сервисы в платформе. До сих пор есть куски кода в разных конфигурациях и обработках, которые вызывают HTTP-сервисы через COM-объект. Когда увидите такой код – сразу вызывайте полицию, это незаконно)).
Но в целом, вы должны быть в курсе. Иначе, когда бизнес к вам придет и попросит: «Хочу вот такое», вы даже ответить ничего не сможете. А скорее всего, платформа давно это умеет и вы это решите в тысячу раз проще.
Еще один элементарный пример – масштабы картинок раньше делали через COMОбъект. Пользователь же не будет разбираться – он вам вгрузит в картинку для этикетки 300 Мб, вы ее должны сжать. Раньше использовали для этой цели COMОбъект. А платформа с версии 8.3.15 умеет это делать встроенными средствами, но почему-то мало кто это использует.
Это очень важная вещь. Даже если вы не хотите обновлять, вы все равно должны это знать. А когда вы об этом узнаете, вы захотите обновить.
В реальности, обновление платформы несет намного меньшие риски, чем обновление конфигурации, чем заливка любого кода из хранилища. При этом в каждой новой версии платформы однозначно есть как и новый функционал, так и исправление ошибок. Ошибки есть во всех системах - в мире не существует более менее сложных систем, не содержащих ошибки.
Платформа – это все-таки одна из самых стабильных частей в мире 1С.
Уменьшай технический долг
Следующий момент – обязательно уменьшайте технический долг. Иначе эта бомба рванет таким баблом, что у вас остановится развитие всей функциональности.
Если у вас уменьшение технического долга прописано только в регламентах, что 10% времени разработчика мы отдаем на технический долг – готовьтесь, что скоро вы будете отдавать 1000% времени разработчика, увеличив их штат в 10 раз, просто на то, чтобы свести технический долг к нормальному показателю.
Я понимаю, все всегда торопятся, у разработчиков всегда дедлайн: «Ой-ой-ой, завтра сдавать. Пока работает – поехали!» Вот это «Работает – поехали» выстрелит очень скоро.
Мы про большие базы говорим, где большое количество данных в таблицах. Неоптимальный код очень быстро выстрелит. Неоптимальная архитектура выстрелит еще быстрее.
Один из свежих примеров в последней версии ERP – при изменении номенклатуры она постоянно пытается перезаписать одну из констант. После этого ERP становится колом из-за блокировки. Зачем так написали – не знаю.
Убирайте этот технический долг, иначе у вас система встанет колом, и чтобы понять что происходит придётся потратить очень много денег, а что ещё важнее очень много времени. А именно время при неработоспособности системы для бизнеса становится дороже денег.
Создай группу качества
Чтобы это было кому делать, обязательно создайте группу качества.
Назовите ее, как хотите. Это – группа людей-экспертов. Обязательно – экспертов. Я не говорю сейчас о том, что у них обязательно должен быть сертификат 1С:Эксперта, но они должны быть очень опытными.
Задача группы качества очень простая – в вашем «городе 1С» не должно быть «красных зданий».
Группа качества занимается оптимизацией кода, анализом техжурнала, рефакторингом кода, поиском и решением технического долга. Она занимается всем-всем-всем, что касается скорости и стабильности.
Если вы эту задачу поставите просто разработчику 1С, он захлебнется. Ему будет некогда. Вы никуда не уберете требование бизнеса – всегда расширять функциональность.
Это – крайне важная вещь, до нее почему-то даже из больших компаний очень мало кто дошел. Но без этого никуда не деться.
В эту группу качества не должно входить 20 человек, там 2-3 человека перекрывают огромный объем работы. Тем более, когда они нарабатывают свои навыки работы с техжурналом и с серверами – они очень быстро вам все стабилизируют и даже ускорят.
Научись работать с техподдержкой фирмы «1С»
И последняя по счету заповедь, но не последняя по значению – научитесь работать с поддержкой фирмы «1С».
Это ваша святая обязанность. Если вы нашли ошибку, потратьте две недели, доказав фирме «1С», что это – ошибка. Я занимаюсь этим круглый год. Мне удается регистрировать ошибки примерно раз в месяц.
Если этого не делать на регулярной основе, опустим пункт, что вы не делаете добро сообществу. Мы обладаем уникальными знаниями – чтобы это работало, тут нужен такой костыль. Мы его нашли, мы молодцы.
Но через год-два ваша система будет состоять из костылей. Потому что фирма «1С» не знает об этой ошибке. Вам повезет, если кто-то другой тоже на нее напорется и сообщит, и добьется, чтобы ее признали, и ее исправят – в зависимости от критичности – через год, через два. Иногда и через месяц – смотря, какая критичность ошибки.
В целом, кто обладает КОРП-лицензиями, у них немного другая техподдержка. Там отвечают быстро. В течение одних суток они в любом случае отвечают. Не робот отвечает, а человек – осознанно что-то требует. Но чтобы грамотно работать с техподдержкой фирмы «1С», вам придется научиться читать техжурнал. Или, как минимум, его собирать. Вам придется организовать у себя стенд, подтверждающий эту ошибку. Это – к разделениям зон. Вы же не будете ошибку подтверждать на проде. Т.е. изолированную зону придется сделать, записать видео, собрать техжурнал, описать весь сценарий. И в большинстве случаев вам фирма «1С» либо подскажет обходной путь, либо укажет на какую-то уже зарегистрированную ошибку, либо признает эту ошибку и исправит.
Я очень надеюсь, что соблюдение этих 10 заповедей плюс ваш опыт, терпение и ум, помогут сделать все инсталляции 1С не только быстрее, но и намного стабильнее.
Дорошкевич Антон, с заботой о вас и вашей 1С!
*************
Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.
