На полях конференции INFOSTART EVENT 2019 Inception нам удалось пообщаться с начальником отдела производительности систем «BIA-Technologies» Сергеем Носковым. Обсудили технологические тренды, перспективы машинного обучения и принципы эффективной работы команды на больших проектах.
Как вам наша конференция?
Все отлично, все нравится.
Сколько раз вы приезжали к нам? В каком качестве?
Как докладчик – третий раз, а так уже пятый, по-моему.
Чем вас привлекает наша конференция?
В основном, конечно, общение. Узнать новые лица. Почерпнуть какую-то новую информацию. Пообщаться с людьми, с которыми думаешь в одном направлении, или наоборот, услышать противоположное мнение.
Какие направления, темы докладов, секции вас интересуют больше всего?
По специфике работы мне интересна секция HighLoad, в которой я выступал, инструментарий высоконагруженных систем. Но стараюсь посещать все секции. В том числе и «Управление». Потому что кругозор надо расширять. Вчера интересный доклад был «Необходимый минимум психологии 1С-ника» – мне очень понравился.
Использовали ли вы у себя в работе какие-то инструменты, приемы, о которых узнали у нас на конференции? Что-нибудь полезное отсюда выносили?
Полезное выносим, конечно – подсматриваем всякие технические моменты, кто как делает, как работает. В прошлом году, например, был доклад Олега Репникова из «Вымпелкома». У него пару идей подсмотрели, за что ему спасибо большое. Переосмыслили, сделали что-то свое. В этом году, в кулуарах, обсудили с коллегами опыт использования сжатия средствами MS SQL и применения Elasticsearch для работы с технологическим журналом. .
Интересуют ли какие-то новые технологические тренды? Может быть, машинное обучение, методы анализа больших данных – применяете?
Основной тренд в последнее время – это автоматизация, DevOps и все, что с ним связано. Тема широкая, и мне, как руководителю отдела производительности, очень близка. Машинное обучение в области контроля за работой системы - перспективное направление. Есть большое желание реализовать подобный инструмент. Задача такая – есть много информации о нагрузке на железо, о состоянии работы программного обеспечения. Ее можно с помощью искусственного интеллекта анализировать, обрабатывать, чтобы система выдавала некое предсказание, ждать ли проблем, какое влияние они могут оказать и какова вероятность их появления.
Это ваш собственный инструмент, собственное исследование или вы где-то какие-то наработки нашли?
Инструмента пока нет. Тема сама по себе непростая. Нельзя так просто взять, скормить кучу данных машине и сказать – решай проблему. Сначала нужно эту проблему ручками определить. Сказать, что на этом этапе точно была проблема – она была такая-то. Найти другие интервалы времени, где эта проблема повторялась и прогнать AI ещё и ещё раз, добиваясь корректной работы машины. Много подготовительной и кропотливой работы, большие инвестиции как времени так и ресурсов оборудования. Думаю это под силу стартапу с поддержкой инвесторов, кто похожий инструмент сделает целью своей работы. Либо коллегам по цеху надо объединяться и пробовать решить эту задачу совместно. Можем помочь – у нас много статистических данных о работе “железа”..
Вы в основном работаете с решениями на платформе 1С – это типовые решения или написанные с нуля? Как они себя проявляют в условиях высокой нагрузки?
Наши основные решения – это самописные базы данных, написанные практически с нуля. С типовыми решениями мы тоже сталкиваемся. Основное – это Бухгалтерия и ЗУП. Там не столько высокая нагрузка, сколько большие объемы данных. В Бухгалтерии, например, была проблема с книгой покупок и с книгой продаж – они просто никогда не формировались за счет больших объемов первички. Поэтому приходилось переписывать запросы, находить пути решения. В последних версиях типовых запрос уже исправили, и, по идее, должно работать «из коробки». Еще с типовыми сталкивались на проектах – проводили нагрузочное тестирование на 5000 пользователей для конфигурации «1С:Документооборот». Также типовое решение «1С:Документооборот» используется в «Почте России» – мы выполняем функцию эксплуатации этой системы. В принципе, «1С:Документооборот» с высокой нагрузкой работает хорошо.
Я думаю, детали этого проекта были бы интересны всем. Расскажите, каким образом организована работа такого огромного количества пользователей в одной базе данных в «Почте России».
База данных не одна, это так называемая распределенка с активным обменом между узлами. Касаемо нашей работы, мы придерживаемся подхода ITSM. С нашей стороны задействовано несколько отделов, это и отдел поддержки пользователей и отделы производительности, администрирования, телекоммуникаций. Главное, чтобы были процессы, чтобы пользователь знал, куда жаловаться, знал, что будет реакция. Обязательно должны быть люди, которые примут задачу, первично обработают, возможно, что-то сразу посоветуют. Если не могут сами решить, передадут на следующую линию поддержки – либо просто разработчикам, либо уже дальше на экспертный уровень. Если уже мы не можем решить, то привлекаем компанию 1С, передаем описание проблемы туда.
То есть, вы выступаете на этом проекте как третья линия поддержки?
Не совсем. Работа поддержки важна, так как пользователи общаются именно с сотрудниками поддержки, но роль нашей компании сложнее. Это не только управление инцидентами и проблемами, но и обеспечение работоспособности после обновлений. Обеспечение контроля за достаточностью мощности инфраструктуры. Также необходимо обеспечить доступность и гарантировать возможность восстановления после сбоев.
И вы считаете этот проект одним из наиболее ответственных, серьезных, трудных?
Да, достаточно сложный проект. Особенно старт проекта, когда мы стартовали. Там было что-то сделано, но много процессов не было описано. Поэтому приходилось все формализовывать, договариваться. Очень много подрядчиков, например, железом владеет одно юридическое лицо, а за безопасность отвечает другое. И для увеличения мощности сервера необходимо получить ресурсы у первого и согласовать со вторыми. Со всеми нужно было наладить контакт, договориться. И у нас получилось.
На большом проекте требуется организовывать эффективную командную работу. Что вам помогает? Какие подходы, методы, инструменты? Как вы управляете людьми?
Этот вопрос будет более уместен руководителям проектов, тем, кто глобально этим занимается. Я руковожу работой своего отдела. У нас есть проекты, которые я веду, как РП. Например, проекты по аудиту, по нагрузочному тестированию. Но в них задействовано мало сотрудников, 1-2 человека. И для меня здесь руководство проектом, это, по сути, руководство людьми. Мне кажется, это в принципе так должно быть. Но процессы должны быть в любом случае. Сотрудник должен понимать, на каком он этапе, куда пойдет дальше процесс, какие сроки, что от него ждут. А управляем мы, естественно, людьми. Управляем и контролируем.
Вы используете какие-нибудь подходы к гибкой разработке? Или у вас больше сопровождение?
В некоторых отделах компании используется Agile. У же нас специфика – оптимизация и производительность. Мало непосредственной разработки.
Там пожары?
Да, там больше жалобы: «Помогите, все горит!». Есть такая-то проблема, что можно с этим сделать? Соответственно, это какая-то исследовательская работа, это предложение вариантов, как это можно было бы решить. И дальше уже переход на следующий уровень. Это может быть оптимизация. Это может быть доработка, разработка какой-то новой архитектуры. Тогда подключаются наши разработчики, архитекторы – сильные команды, которые все умеют, все знают.
В любом случае вы сотрудничаете еще и со смежными командами для того, чтобы добиваться результатов?
Да, может быть такое.
Как вы оцениваете результативность, эффективность работы в своей команде, используете ли эти критерии в мотивационной составляющей?
Оценки две. Первая оценка – по срокам работы. Если был обещан какой-то срок – надо соблюдать. Есть набор задач, у которых мы совместно с сотрудником сами определяем срок. Даже больше он здесь вклад вносит – говорит: «Я сделаю к такому-то числу». Если ты обещаешь сделать, держи слово. И второе – это как раз таки мотивационная часть, которая завязана на показатели работы системы. Это доступность и индекс производительности. Эти параметры влияют в том числе и на размер вознаграждения.
То есть, если удалось оптимизировать, мотивационная составляющая повышается?
Если обеспечивается требуемый уровень доступности и APDEX, то выплачивается премия. А уже как удалось это обеспечить - оптимизацией или изменением настроек кластера серверов, не так важно.
А конкретно в вашей отрасли существует ли проблема нехватки кадров? Тяжело ли найти специалистов, которые могли бы разобраться в проблемах производительности?
Да, и у нас в отделе, и в отделах разработчиков у коллег, хороших программистов найти сложно. А ребят, которые обладают экспертными знаниями по технологическим вопросам – особенно, если есть практический опыт – таких вообще очень сложно найти, они все уже пристроены. Поэтому здесь самое главное – найти ребят с правильным складом мозгов, как я называю. Когда ты общаешься и понимаешь, что да – достаточно подсказать такие-то вещи, и человек уже может влиться в команду и начать практиковать и работать.
Личностные особенности человека для вас играют решающее влияние при подборе команды?
Не то, что личностные – наличие татуировок или косичек меня не смутит, а в том плане, что, например, производительность – это некое состояние духа, когда ты должен постоянно что-то исследовать и докапываться до истины. Вот эта способность важна. Ведь в какие то моменты работа кропотлива, нудна и неинтересна. А иногда это, наоборот, некий вызов для себя – докопаться до истины. Ответить на вопрос «Почему же это именно так?». Плюс, все-таки, специфика знаний. Как минимум, человек должен хорошо понимать, как устроена база данных, сервер MS SQL, Postgres.
У вас Postgres тоже используется?
Используется, но больше всего используется MS SQL Server. По разным причинам. В Enterprise чаще всего используется MS SQL Server. Postgres сейчас входит в госкомпании. Они при выборе СУБД, скорее всего, будут заинтересованы именно в Postgres. Большой Enterprise все равно пока работает на MS SQL сервере.
Но перспективы Postgres все равно есть, и вы не исключаете, что когда-нибудь на него перейдете?
Перспективы точно есть. Особенно, на проектах, которые изначально стартуют. На небольших проектах. Опять-таки, для команд самих разработчиков, я считаю, обязательно нужно использовать. Это бесплатный продукт, имеет большую функциональность. В Postgres нюанс в том, что он не обладает развитыми инструментами для визуального анализа проблем. И если в MS SQL Server есть достаточно много динамических представлений, так называемых вьюшек, по которым можно детально разобрать поведение СУБД – вплоть до того, какие данные, в какой странице памяти лежат, какие данные сейчас вытеснили оперативку – можно увидеть все эти технические моменты. То для Postgres не всегда есть инструменты и информация, чтобы быстро “размотать” первопричины проблемы. Надо быть более погруженным в техническую часть. Это другое направление знаний. Здесь ты уже сам немного становишься разработчиком Postgres как платформы, понимаешь ее устройство именно на уровне архитектуры, а не просто отслеживаешь поведение работы базы данных Проще говоря, MS SQL Server легче мониторить и контролировать. Мониторинг по Postgres реализовать сложнее. Возможно дело в нехватке информации и реальных примеров траблшутинга.
Хочу немного спросить про сообщество. Вы у нас на сайте давно, пользуйтесь ли какими-то разделами, сервисами?
Обязательно смотрю секции «Рекомендации экспертов», «В центре внимания», за новостями слежу. Захожу, комментирую, общаюсь, высказываю свою точку зрения. Кого-то поддерживаю, кого-то молча не поддерживаю. Есть моменты, когда хочется подискутировать, сказать, что человек явно не прав: «в интернете кто-то не прав» - знакомый всем мем. С другой стороны, ты можешь думать, что человек ошибается, а на деле это другой опыт, другое мнение, другая философия. Это, наоборот, интересно, привлекает внимание. Ты смотришь, что человек как-то по-другому взглянул на проблему, на какие-то вещи, и пытаешься понять, переосмыслить, и иногда это тебе подходит и помогает развиваться, а иногда ты говоришь – я по-своему сделаю.
У нас многие участники сообщества отмечают, что в мире 1С своя особая атмосфера. Насколько вы считаете, есть ли какие-то специфические отличия от других сообществ, от других языков программирования?
У меня нет опыта в других сообществах программирования. У меня есть опыт совсем других сообщество – я работал после школы стропальщиком. Мы выгружали бревна из Волги и грузили в вагоны. А после университета я какое-то время работал на химзаводе, инженером-механиком и руководил бригадой слесарей-ремонтников. Конечно, в сравнении с этими сообществами, программисты отличаются принципиально. Программист, даже если не имеет высшего образования, то склад ума у него все равно инженерный . У меня такая ассоциация. Программист – всегда инженер.
Инженер с точки зрения того, что он исследователь, что он все прикладное пытается применить ради конкретной цели?
Инженер – это такое состояние духа. У человека, который прошел высшее образование, мозги уже работают немного по-другому, чем у того, кто после школы просто работал на заводах со станками. Не умаляю труд станочников – у меня отец долгое время работал за станком. Но инженер больше работает головой, потому что ему важно не просто деталь выточить, а чтобы все было правильно – деталька за деталькой в нужной последовательности собрались в итоге в какой-то большой работающий механизм. Так же и программист – он тоже думает, в основном, головой. И тоже всегда разрабатывает какую-то большую штуку, которая должна в идеале заработать.
Но это же не просто большая штука – это все-таки бизнес-приложение?
Это может быть небольшая функция, а может быть отдельная база данных с нуля. Это может быть просто сервис какой-то.
Тема этой конференции – это идеи. И Доржи Цыденов на открытии говорил, что мы даем нашим участникам вдохновение, мотивацию, идеи. А каким образом вы вдохновляетесь? Как вы находите информацию, которая заставляет вас двигаться в нужном направлении?
Она как-то сама приходит. Тут главное не переставать читать, потреблять информацию. Иметь для себя несколько источников этой информации, следить за новостями, за тем же сайтом Инфостарт, партнерским форумом 1С. Участники сообщества публикуют свое мнение, свои разработки – смотрите, какую штуку изобрел. И ты волей-неволей всегда получаешься в тренде. Помимо сайта, наверное, какая-то техническая документация. Например, у нас каждый год проходят встречи с инженерами Microsoft.. Они показывают примеры и варианты решения проблем, мы задаем вопросы по актуальным кейсам проблем, ищем способы решения.
Это полезно – обмен информацией между сообществами. Очень важно. Какие-то проблемы мы совместно исследуем. Мне казалось, что мы думали изначально, что первопричина в этом, а первопричина оказалась чуть глубже, чуть сложнее. А иногда это ошибка работы программного обеспечения. Бывает и так.
А какие у вас планы на ближайшее будущее?
Хотим разработать мониторинг. Работаем сейчас над своей системой мониторинга. Пока туда искусственный интеллект не прикручиваем.
Но вы еще не делились информацией о своей системе мониторинга?
Нет, еще не делились. Рабочий вариант у нас есть, уже на нескольких системах настроено и не раз нам помогала, выручала. Хотелось бы ее немного причесать, допилить.
Но вы там используете Grafana, например?
Именно Grafana и используем. Почему сами начали делать? Мы понимаем, что нам надо, и инструмент интересен не только как мониторинг в части «Предупредить о чем-то», а именно как инструмент, который помогает расследовать какие-то проблемы. Это важно. Таких инструментов, на самом деле, не много на рынке. Я могу сказать, что это – PerfExpert от компании SoftPoint и сервисы Вячеслава Гилева, и там и там нацеленность на то, чтобы помочь расследовать проблему, докопаться до истины. Мы тоже хотим сделать инструмент, который помогал бы определять причины, быстро находить зависимости одного события от другого. И устанавливать именно причины проблемы.
Что бы вы посоветовали начинающим разработчикам, которые только встают на путь 1С?
Вспоминая свой опыт, я бы посоветовал больше практики. А с точки зрения, как руководитель отдела по производительности, советую углубиться на уровень абстракции СУБД. Нас фирма «1С» пытается с этого уровня вывести – «работайте, ребята, с объектами метаданных, с конфигурацией». Но, тем не менее, обязывает иметь эти знания для экспертов по технологическим вопросам. И это, как раз-таки, тема доклада, с которым я выступал. Получается, что чтобы качественно разрабатывать базы данных, эти знания нужны. Но, тем не менее, их пытаются убрать “за скобки”. Следуя этой логике, чтобы качественно разработать базу данных, нужен эксперт. Только у него должны быть все знания. А это – неправильно. Так быть не должно. Потому что у эксперта шире круг задач. Он, скорее, чинит потом за программистами, за разработчиками, чем сам разрабатывает. А надо идти к тому, чтобы каждый программист, каждый разработчик мог правильно и хорошо разработать архитектуру, качественно выполнить свою задачу, свою работу.
Может быть, в нашей отрасли просто не хватает каких-то базовых знаний, которые можно было бы доступно донести?
Да. И я попытался в докладе донести свое видение. Я часто бываю на собеседованиях, мы общаемся с ребятами-программистами. И вот как раз-таки уровень знаний, как работает СУБД, часто отсутствует. И, соответственно, я показываю – обрати внимание, почему этот запрос работает быстро, а этот – медленно. Потому что здесь есть индекс, а здесь нет индекса, а здесь у тебя другие условия в запросе. Это не должен быть набор каких-то метрик и стандартов – пиши именно так, так и так. Человек должен уметь сам, обладая определенной информацией, знаниями, сделать вывод – будет это работать хорошо или не будет? Какая архитектура регистра будет здесь более оптимальна? И, чтобы самостоятельно делать такие выводы и нужно знание и понимание, как работает база данных, как работает запрос в базе данных, что такое план запроса. Что такое, в принципе, индекс, почему, если одно поле индекса пропускаешь в условии отбора, он работает медленно. Почему важен порядок измерений в регистре сведений, а не важен порядок реквизитов в документе. Такие моменты – на них очень легко получаешь ответы, когда опускаешься до абстракции работы базы данных.
То есть, вы советуете начинающим разработчикам укреплять свой базовый уровень в смежных отраслях?
В смежных, наверное, тоже, хотя, это уже, наверное, следующая рекомендация. Чтобы не застаиваться, развиваться дальше. Но если ты – начинающий, пойми, что самое главное в базе данных – это запрос. И научись писать качественную архитектуру. Наверное, так.
