👉 Какие бывают инструменты мониторинга в DevOps?

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

Независимо от того, хотите ли вы контролировать Kubernetes, IoT-устройства или аппаратные серверы, правильный инструмент мониторинга поможет сделать это возможным.

Эффективный инструмент мониторинга повышает производительность системы, а также помогает сократить (или даже устранить) время простоя. Можно правильно планировать обновления и новые проекты, а также лучше распределять свое время и ресурсы. Вы можете обнаружить проблемы и решить их прежде, чем они повлияют на пользователей.

▶️ Рассмотрим наиболее часто используемые в DevOps-инструменты мониторинга в нашей статье: https://efsol.ru/promo/devops-monitoring.html

🔥 Миграция с MSSQL на PostgreSQL для конфигураций 1С - неизбежность?

В связи с различными ограничениями использования зарубежного ПО, например, остановкой обновлений, продаж и поддержки, блокировкой аккаунтов - все больше компаний изучают возможности миграции на другие программные продукты, которые не затрагивают санкции.

В 2022 году актуален вопрос ухода от продуктов Microsoft, не исключение здесь использование Windows Server и MS SQL в связке с 1С.
Если изучить список совместимости операционных систем с сервером 1С, то их более десятка, а вот альтернативная СУБД только PostgreSQL.

👉 Как перейти? Упрощенно:

1) Развернуть сервер, настроить ОС и СУБД.
2) Перевести базы 1С на PostgreSQL.
3) Провести тестирование работоспособности.
...или еще проще - обратиться к нам в EFSOL Oblako (https://efsol.ru/cloud/).

👉 А что с производительностью?

Три года назад мы уже проводили исследование, которое показало, что с производительностью 1С на PostgreSQL порядок и многое зависит от настройки: https://efsol.ru/articles/1s-sql-test.html

🔥 Сворачивание SPLA от Microsoft — что делать?

Важная новость — это уход программы Microsoft SPLA из России и всего СНГ, включая все среднеазиатские республики, Кавказ и Белоруссию с Украиной.

Microsoft SPLA позволяет сервис-провайдерам и дата-центрам сдавать клиентам лицензии Microsoft в аренду с помесячной оплатой. Модель ухода во всех странах, в том числе и России следующая — новые соглашения не заключаются уже сейчас и когда истекает срок соглашения у партнера, его не продлевают.

Так произошло, например, с Yandex Cloud, где с 15 августа ограничена возможность создания новых сервисов на базе продуктов Microsoft, а 31 августа произойдет отключение KMS-серверов, которые отвечают за лицензирование сервисов SQL Server, Windows Server и RDS. Также будут остановлены кластеры Managed Service for SQL Server, сервисы Loginom и Kaspersky, которые базируются на Windows Server, также потеряют свои лицензии.

Официально Microsoft заявляет, что это связанно с дальнейшем улучшением этой программы, что бы сделать ее более удобной. Но, скорее всего, это связано с тем, чтобы продвигать программу CSP. Эта программа перепродажи облачных услуг Microsoft, а именно Office 365 и Azure. Скорее всего, эта программа для Microsoft гораздо выгоднее и гораздо лучше контролируется вендором, нежели SPLA. Есть очень большие сомнения, что программа SPLA вернется после "оптимизации и улучшения", надо учиться жить без нее.

Есть задачи по миграции с продуктов Microsoft? Обращайтесь: https://efsol.ru/it/

☝️ Как добиться того, чтобы проект по запуску ERP-системы был успешен?

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

✅ Руководитель проекта поделился стратегией развертывания системы

Руководитель проекта должен предупредить членов проектной группы, сотрудников компании и любую третью сторону, которая будет использовать новую ERP-систему о действиях, которые будут выполняться до и после ввода в эксплуатацию. Обмен стратегией поможет всем спланировать свою работу, независимо от того, будут ли они отвечать за последние исправления и обучение или просто будут использовать новую систему.

✅ Миграция данных завершена

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

✅ Критичные ошибки устранены

Перед запуском команда проекта должна устранить ошибки, обнаруженные на заключительном этапе реализации. Скорее всего, до запуска не будут исправлены все ошибки, но нужно проверить каждую из них на предмет критичности и создать план по устранению каждой. Например, команда может исправить критические ошибки перед вводом в эксплуатацию, но отложить исправление мелких проблем до следующего этапа реализации.

✅ План обучения готов

Прежде чем система ERP будет запущена, нужно запланировать обучение, назначить инструкторов для проведения необходимых учебных занятий и уведомить сотрудников, которым необходимо будет пройти обучение.

✅ Уведомление о проекте получили все стороны

Команда проекта обычно рассылает официальное сообщение о внедрении ERP незадолго до и после запуска. Сообщение о проекте может включать заметку во внутренней сети компании, электронное письмо сотрудникам и телефонные звонки любым третьим сторонам, которые будут использовать новую систему ERP, например внешним поставщикам.

✅ Производственная среда готова

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

✅ Доступность ресурсов обеспечена

Руководитель проекта должен убедиться, что все необходимые ресурсы, включая сотрудников и внешних подрядчиков, будут доступны для поддержки новой системы ERP после запуска.

✅ Тестирование работоспособности проведено

Нужно выполнить перечень основных тестов работоспособности, чтобы убедиться, что система ERP работает должным образом. Тесты могут быть как автоматическими, так и ручными. Нужно убедиться, что все критичные функции работают правильно.

✅ Доступ к старой системе ограничен

Команда проекта должна гарантировать, что сотрудники не смогут добавлять новые данные в старую систему после перехода на новую.

Есть задачи по переходу на 1С:ERP? Обращайтесь к нам! https://efsol.ru/

🔥 SonarQube для отслеживания качества кода 1С

В процессе разработки на 1С, может накапливаться технический долг, те проблемы, на устранение которых в дальнейшем потребуется существенное количество ресурсов.

Почему эти проблемы возникают:

- нет тестирования кода;
- плохая архитектура;
- нет документации;
- некомпетентность кадров;
- давление бизнеса;
- не проводится код-ревью.

Классическим средством борьбы с техническим долгом является аудит, как внутренний, так и внешний. Но чтобы исключить влияние человеческого фактора, можно автоматизировать проверки с помощью подхода continuous code inspection (непрерывная проверка кода). Это можно сделать, например, используя SonarQube (https://www.sonarqube.org/downloads/) c плагинами для 1С:

https://github.com/1c-syntax/sonar-bsl-plugin-community
https://silverbulleters.org/sonarqube

Благодаря SonarQube, можно наглядно оценить качество кода.

👉 В нашей статье мы приводим пример использования SonarQube как части процесса CI/CD в разработке 1С: https://efsol.ru/promo/devops-1s.html

🔥 Время не ждет: выпуск обновлений 1С:УПП скоро прекратится

Фирма 1С прекратит поддерживать 1С:УПП в 2026 году. Это серьезный повод переходить на более современную систему и не подвергать свои бизнес-процессы лишнему риску.

👉 Почему стоит перейти на 1С:ERP?

Конфигурация обновляется и развивается фирмой 1С.
Полноценный производственный учет со встроенным блоком ремонтов.
Поддержка БУ, НУ, международного и управленческого учета.
Расширенный функционал в подсистеме обеспечения потребностей.
Актуальная платформа 1С 8.3, поддержка веб-доступа и мобильных устройств.

👉 Особенности перехода с 1С:УПП на 1С:ERP

➜ Самостоятельно

Нет возможности подготовить план-график. Как правило не учитываются особенности системы. Из-за этого срок проекта некорректный. Вы не можете планировать трудозатраты и бюджет.

Дорого содержать команду внедренцев в штате компании. В 1C:ERP более 7 блоков по которым разработаны курсы 1С. Один человек все знать не может. Так же на проект нужен руководитель проекта. Проект может двигаться очень медленно без сильной команды.

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

Могут быть лишние затраты на содержание 2х серверов (разработка и продакшн). Необходима тестовая среда для разработки и перехода на 1С:ERP. Требуется приобрести или арендовать серверные ресурсы и программное обеспечение, а также оплатить обслуживание.

Потери времени на изучение стандартов написания проектной документации. Требуется описать документацию по всем объектам учета в общепринятых стандартах. Это очень трудозатратный процесс, требующий специфических знаний и опыта.

➜ С помощью EFSOL

Есть готовые шаблоны проверенные в проектах. Большой опыт реализации проектов 1С:ERP. Мы готовим план перехода, которому можно доверять. Мы остаемся в рамках лимита времени и бюджета.

В штате более 400 специалистов по разным направлениям. Мы имеем все статусы от 1С, что означает наличие в нашем штате специалистов в разных отраслях. Опыт подтвержден сертификатами от фирмы 1С и полученными отзывами довольных клиентов.

Есть финансовые гарантии. Предоставляем их на сервисы и работы проекта. Мы предоставляем финансовую гарантию на работоспособность ПО и сервера. Мы компенсируем простои. Предоставляем гарантию на выполненную разработку.

Нет лишних затрат. Сервер для разработки (или продакшн) даем в аренду. Мы предоставляем клиентам серверы разработки с необходимым программным обеспечением, полным техническим обслуживанием, резервным копированием на срок проекта.

Использование опыта прошлых проектов. Использование наработок EFSOL и фирмы 1С. Мы собрали воедино стандарты проектирования бизнес-процессов в Метод EFSOL. Метод позволит составить документацию таким образом, чтобы не было зависимости от команды разработки, релиза ПО и этапа проекта.

👉 Узнайте больше: https://efsol.ru/promo/upp-erp.html

🔥 Gitlab-сервер в Docker compose

Для тех, кто хочет быстро установить свой Gitlab-сервер и удобно управлять развертыванием и масштабированием данного сервера в дальнейшем, мы записали видеоинструкцию.

Минимальные требования:

Как минимум 4 ГБ ОЗУ;
ОС с поддержкой docker engine и docker-compose (мы использовали Ubuntu 20.04 LTS);
Если требуется публикация — то потребуется белый IP с доменным именем и пробросами портов 22, 443 и 80.

Видео: https://www.youtube.com/watch?v=NoCdPYWEMc4

🔥 Как справляться со стрессом на работе?

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

Мы не всегда можем контролировать то, что происходит вокруг, но мы всегда можем контролировать то, что происходит внутри нас. Поэтому, для оперативного снятия стресса, возьмите паузу и примените эти методы релаксации:

👉 Шаг 1. Вдох-выдох.
Помните, как в фильмах медики или пожарные в неприятной ситуации советуют дышать глубоко и спокойно. А все потому, что в стрессовых ситуациях организм испытывает кислородное голодание, дыхание учащается. Поэтому первое, что нужно сделать – это обеспечить доступ кислорода к головному мозгу. Не обязательно идти в студию йоги, чтобы ощутить все преимущества глубокого дыхания, можно быстро, эффективно и незаметно сделать это даже в многолюдном офисе. Просто вдохните на четыре счета, а затем также на четыре счета выдохните.

👉 Шаг 2. Мышечная релаксация.
С помощью этой техники снимаем мышечное напряжение, возникающее в результате стресса. Вам нужно напрягать, а затем расслаблять основные группы мышц в течение пяти секунд на каждую. Это поможет замедлить дыхание и сердцебиение, стабилизировать кровяное давление и расслабиться.

👉 Шаг 3. Созерцание природы.
Прогулка до ближайшего парка, отдых в окружении зелени и свежего воздуха минимум раз в день — мощное и бесплатное лекарство от стресса, всегда доступное и обладающее продолжительным эффектом.

А что сделать ещё?

1) Налаживайте связи. Круто, когда рядом есть коллеги, которые будут способны поддержать вас в стрессовой ситуации.
2) Заботьтесь о теле. Физические упражнения и дыхательные практики в перерывах от работы помогают снизить уровень тревожности.
3) Откажитесь от вредных привычек и быстрых перекусов за рабочим столом, делайте перерыв и правильно питайтесь.
4) Спешите медленно. Если мы будем делать каждую вещь спокойно и осторожно, то сможем сделать все быстрее и с гораздо меньшим напряжением.

Используйте вышеприведенные методики и ловите “дзен”, и ваша жизнь заиграет новыми краскам. Вы заметите, как станете более продуктивными, позитивными и готовыми к новым задачам.

👉 Как изменился рынок международной логистики в 2022 году?

С марта 2022 года после введения дополнительной серии санкций, работа международных логистических провайдеров на рынке РФ значительно ухудшилась. Это стало похоже на какой-то квест. Схемы доставки и оплаты услуг, которые были разработаны ранее, могли стать не актуальны на следующий день.

Отказ иностранных компаний от партнерства с российскими контрагентами, резко снизил объем грузопотоков из Европы. Из России ушли более 15 крупных европейских транспортных компаний, многие из которых являлись собственниками контейнеров. Возможность прямой доставки грузов из ЕС в РФ стала использоваться реже, да и сложнее. Все больше стран официально закрывают свои порты для захода российских судов и российских грузов. Российские импортеры стали искать замену своим европейским поставщикам в Юго-Восточной Азии, в основном, в Китае. Поэтому стал популярен вариант комбинированной доставки, море+ж/д или автомобильным транспортом из Китая через порты Дальнего Востока.

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

Предполагается, что к ноябрю-декабрю можно ожидать не просто стабилизации ситуации, но и выстраивания новых логистических схем и цепочек.

👉 Чтобы быть готовым к изменениям, нужно настроить бизнес-процессы. Наше решение по автоматизации и управлению транспортно-логистическими процессами по ссылке: https://efsol.ru/solutions/transport-logistics.html

🔥 Proxmox вместо Hyper-V и VMWare — какие могут быть нюансы?

В связи с уходом из России крупных ИТ-вендоров типа Microsoft или VMWare, становится актуальным переход на OpenSource-решения в сфере виртуализации.

У себя мы выбрали в качестве альтернативы — Proxmox. В целом, очень достойный гипервизор, особенно, если учитывать тот факт, что он бесплатный. Но есть нюансы, которые надо учитывать при эксплуатации. Расскажем об одном из таких нюансов, а именно — об обновлении Proxmox.

Во время работы кластера Proxmox, мы 2 раза поймали непонятный сбой с двумя нодами, когда они неожиданно отваливались по сети. Изучая форум разработчика, нашли описание проблемы, где одна из первых рекомендаций была провести обновление. У нас стояла стабильная версия Proxmox 7.1, соответственно, было принято решение обновляться до актуальной версии 7.2.

Сказано-сделано. И тут выяснилось, что в новой версии не работает живая миграция между нодами, виртуалка при миграции падает. Дальнейшее изучение форума показало, что это известная проблема в ядре 5.15.39-3-pve для некоторых типов процессоров. И нам очень повезло, что буквально на днях вышло пропатченное ядро 5.15.39-3-pve-guest-fpu, в котором баг исправлен. Если бы мы сразу после выхода стабильной версии 7.2 стали обновляться, то вынуждены были либо откатываться, либо жить без миграции пару месяцев до исправления бага.

👉 Выводы при работе с Proxmox:

1) Не стоит ставить свежие обновления без острой необходимости. Надо дать обновлению "настояться" для выявления критичных багов.
2) Нужно обязательно иметь тестовый стенд с максимально идентичным железом, чтобы перед обновлением проверять работоспособность основных функций.

На текущий момент ощущения от эксплуатации Proxmox следующие: продукт вполне работоспособен и к использованию годен, но нужно быть аккуратным и внимательно все предварительно проверять на тестовом стенде. А на сэкономленные от закупки лицензий VMWare и Microsoft деньги нужно обязательно закупить и собрать этот стенд.

🔥 Управляй и успевай: ТОП 3 техник управления временем

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

Фрилансеру, студенту, специалистам разных отраслей, и даже «многорукому осьминогу» чтобы оставаться продуктивным, необходимо правильно планировать свой день, оставляя свой фокус на важном, не отвлекаясь на вторичное. Предлагаем ознакомиться с 3-мя ТОПовыми техниками управления временем:

⏰ Техника «Pomodoro» или система 25 минут, спасшая судьбу многих проектов и зарекомендовавшая себя, как средство номер 1 по борьбе с прокрастинацией. Суть проста - ставим таймер на 25 минут и работаем, ни на что не отвлекаясь. Далее 5 минут отдыха и заново, и так 4 цикла подряд. Потом можно устроить перерыв в течении 30 минут.

⏰ Матрица Эйзенхауэра предполагает рассортировать дела по их срочности и важности и отнести к каждому из четырех типов, указанных ниже:
- Важные и срочные
Могут привести к значительным потерям, ущербу
- Важные несрочные
Ориентированы на будущее, на профилактику проблем
- Неважные срочные
Рутинные задачи , обязательные к выполнению
- Неважные несрочные
То отчего можно и нужно избавиться (пустая трата времени)

⏰ «Съешь лягушку», конечно, не в прямом смысле. Суть в том, чтобы начать день с самой трудной и неприятной задачи и сделать её так быстро, насколько это возможно.

В основе всех методик управления временем лежат три компонента:
- выделение приоритетной задачи;
- планирование задач, определение её сроков;
- структурирование задачи.

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

P.S. этот пост появился на свет, благодаря использованию техники «Pomodoro». 😊

👉 В чем разница между виртуальной машиной (ВМ) и контейнером?

Начинающие ИТ-практики не всегда понимают разницу между виртуальной машиной и контейнером. Расскажем кратко, в чем отличия, преимущества и недостатки.

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

👉 Так в чем же разница?

Виртуализация обеспечивает одновременную работу нескольких ОС на одном компьютере:

- каждая ВМ имеет свою ОС
- долго запускается, много "весит"
- производительность ограничена
- более безопасно за счет полной изоляции
- виртуализация на уровне "железа"

Контейнеры работают на одной и той же ОС, изолируются только процессы:

- используется нативная ОС
- запускается мгновенно, занимает не так много места
- нативная производительность
- менее безопасно, т.к. изоляция на уровне процесса
- виртуализация на уровне ОС

👍 Для того, чтобы посмотреть на контейнеризацию вживую, можно использовать Docker Desktop for Windows — это Community-версия Docker для систем Microsoft Windows, которая достаточно просто устанавливается, например, на Windows 10.

🔥 2 мифа о внедрении 1С:ERP, которые мы опровергли на опыте своих проектов

Специалисты команды EFSOL вместе с финансовым директором «СФТ Пакетджинг» Нагметовой Галиной выступили на корпоративном тренинге. Мероприятие было организовано в одном из филиалов группы СФТ в г. Алексине. Наша команда выступала с докладом «Автоматизация блока «Закупки» на базе 1C:ERP.

Мы поделились результатами внедрения 1С:ERP, которая сейчас является основной учетной системой «СФТ Пакеджинг». И в процессе запуска 1С:ERP развеяли сразу 2 мифа о ее внедрении:

👉 Миф 1 - «1С:ERP невозможно запустить без доработок»

Реальность: 3 филиала и головная компания работают в типовом функционале. Система на поддержке, «замочек не снят».

👉 Миф 2 - «1С:ERP невозможно запустить без проектного подхода и длинных аналитических этапов»

Реальность: моделирование процессов четырех разных филиалов произвели за 4 месяца, свели учетные политики и запустились!

На тренинге мы также рассмотрели следующие вопросы:

- Архитектура ERP. Акцент сделали на функционале блоков, которые влияют на закупочную процедуру.
- Возможности блока «Закупки». Простой и быстрый способ реализации блока.
- Возможности блока «Казначейство», в том числе планирование и управление денежными средствами.
- Ожидаемые выгоды и эффект от внедрения.

А сейчас мы готовы развеять еще один миф: «Блок Закупки в типовом функционале нельзя запустить за 3 месяца».
Вызов принят ;)

🔥 Какие KPI есть в DevOps? Часть 1.

DevOps рассматривается как важный компонент процесса доставки и развертывания программных продуктов. Ключевые процессы DevOps участвуют во всем — от обеспечения безопасности до поддержки приложений. Даже лучшие практики DevOps не гарантируют качество, а иногда могут даже вызвать больше проблем, если не интегрированы должным образом. Стремясь как можно быстрее доставить программное обеспечение на рынок, компании рискуют получить много ошибок, которые будут обнаружены конечными пользователями.

DevOps, как и другие современные процессы, требует тщательной интеграции ключевых показателей эффективности (KPI). Правильные метрики могут гарантировать, что приложения работают с максимальной пользой.

👉 Рассмотрим основные показатели KPI, которые используются на практике:

► Частота развертывания (Deployment Frequency) - обозначает частоту запуска новых функций или возможностей. Частота может быть измерена на ежедневной или еженедельной основе. В идеале, показатели частоты либо будут оставаться стабильными во времени, либо будут наблюдаться небольшие и устойчивые увеличения. Если высокая частота приводит к увеличению времени развертывания или более высокой частоте и количеству отказов, возможно, необходимо снизить частоту развертывания до тех пор, пока существующие проблемы не будут решены.

► Объем изменений (Change Volume) тесно связан с частотой развертывания и определяет количество новых пользовательских историй или изменений кода, которые команда DevOps предоставляет с каждым выпуском или за определенный период времени. Хотя большой объем изменений может быть признаком эффективного итеративного подхода к продукту, он также может быть индикатором слишком узкой нарезки проекта и изменений, происходящих исключительно ради изменений.

► Время развертывания (Deployment Time). Несмотря на то, что короткое время развертывания имеет важное значение, оно не должно идти за счет корректности релизов. Увеличение числа ошибок может указывать на то, что развертывания происходят слишком быстро.

► Частота неудачных развертываний (Failed Deployment Rate) - это число должно быть как можно ниже. На процент неудачных развертываний часто ссылаются наряду с объемом изменений. Низкий объем изменений наряду с увеличением частоты неудачных развертываний может указывать на проблему где-то в рабочем процессе.

► Частота отказов (Change Failure Rate). Низкая частота отказов позволяет предположить, что развертывания происходят быстро и регулярно. И, наоборот, высокая частота отказов означает плохую стабильность приложений, что может привести к проблемам у конечных пользователей.

► Среднее время до обнаружения (Mean time to discovery). Хотя идеальное решение состоит в том, чтобы минимизировать или даже искоренить неудачные изменения, важно быстро обнаруживать сбои, если они происходят. Время на обнаружение может определить, адекватны ли текущие меры по реагированию.

► Среднее время между сбоями (Mean Time Between Failures) - является метрикой надежности и доступности. Она используется для измерения способности системы или компонента выполнять свои требуемые функции в установленных условиях в течение определенного периода времени. Кроме того, MTBF позволяет команде разработчиков DevOps измерить степень работоспособности системы или ее компонент.

► Среднее время восстановления (Mean Time to Recovery) - это важный показатель, который указывает на способность адекватно реагировать на выявленные проблемы. Быстрое обнаружение мало что значит, если за ним не следует столь же быстрое восстановление.

DevOps-услуги: https://efsol.ru/promo/devops.html

🔥 Выбираем фотографию для резюме

"Я не фотогеничен!" — эту фразу можно услышать не только от стеснительных девушек, но и от брутальных парней. Мы не будем в данной статье обсуждать, стоит ли размещать свое фото в резюме, есть различные мнения на этот счет и многое зависит от той должности, на которую вы претендуете. Наша рекомендация — размещайте, это повысит шансы вашего резюме быть просмотренным.

👉 А вот какой должна быть фотография в резюме, давайте, рассмотрим подробнее:

1) На фотографии изображены только вы.
Ни с кошкой на руках, ни с ребенком на линейке, ни в клубе с друзьями или женой на свадьбе.

2) Вы сфотографированы крупным планом (желательно по пояс), сидите/стоите прямо и смотрите в камеру.
Снимки со спины, полубоком, либо на фоне, например, водопадов, где вас даже не рассмотреть, в данном случае неуместны.

3) Обстановка и фон на фотографии нейтральны, либо серьезны.
Возможно, вы себе очень нравитесь на снимке из бара с бокалом в руке, но оставьте его все-таки для других целей.

4) Снимок качественный.
Ваше лицо четко видно, ваш друг не замазан в фотошопе.

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

6) Прикрепляйте актуальные фотографии.
На собеседование должен прийти человек, соответствующий фотографии. Если вы создали резюме 5 лет назад, то обновите не только раздел "опыт и навыки", но и фотографию.

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

Если ваша фотография в резюме не соответствует данным критериям, рекомендуем перефотографироваться и прикрепить новое фото. А вдруг вы получите оффер мечты?! Рискните :)

P.S.: если нет подходящих фотографий и фотографироваться нет желания, то лучше не прикрепляйте ничего.

🔥 Какие KPI есть в DevOps? Часть 2.

При отслеживании ключевых метрик DevOps необходимо сосредоточится не на плюсах или минусах, основанных на каком-либо одном показателе, а скорее на статистике, которую эти метрики показывают, когда совместно анализируются.

Ссылка на 1 часть

👉 Продолжаем рассматривать основные показатели KPI, которые используются на практике:

► Скорость ухода от ошибок (Defect Escape Rate)

Каждое развертывание программного обеспечения сопряжено с риском появления новых ошибок. Они могут не быть обнаружены, пока тестирование не будет завершено. Хуже того, они могут быть найдены конечным пользователем. Этот параметр отслеживает, как часто ошибки обнаруживаются на этапе предварительного тестирования по сравнению с продакшн-средой. Эта цифра может служить ценным показателем общего качества выпусков программного обеспечения.

► Время выполнения (Lead Time)

Время выполнения отображает информацию об эффективности всего процесса разработки. Этот показатель также указывает на текущую способность удовлетворять растущие потребности пользователей. Время выполнения начинает свой отсчет, когда от пользователя поступил запрос и заканчивается, когда запрос полностью выполнен. Частью Lead Time является Process Time — время за которое по факту выполнен пользовательский запрос. Отсчет начинается когда команда приступила к выполнению задачи до полного выполнения запроса.

► Объем ошибок (Defect Volume)

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

► Доступность (Availability)

Доступность указывает степень простоя для данного приложения. Это может измеряться как полной, так и частичной доступностью. При этом для планового технического обслуживания может потребоваться некоторое снижение доступности. Тщательно отслеживайте как запланированные простои, так и незапланированные отключения, помня о том, что 100-процентная доступность может оказаться невозможной.

► Соответствие SLA (SLA compliance)

Время безотказной работы приложений является важным показателем для каждой ИТ-организации. Соглашения об уровне обслуживания требуют, чтобы инфраструктура, службы и поддерживающие приложения соответствовали высокой цели доступности. Сервисы должны быть в максимально возможной степени доступны пользователям, что позволяет достигать SLA 99,99%.

► Незапланированная работа (Unplanned Work)

Этот показатель помогает отслеживать как качество выпусков программного обеспечения, так и общую продуктивность команды DevOps. Определите объем работы для выпуска в начале цикла DevOps и сравните его с фактической работой, необходимой для завершения выпуска. Чем больше времени разработчики и администраторы тратят на незапланированную работу, такую как устранение ошибок в производственной среде, тем хуже. Возможно, существует недостаток тестирования или разрыв между средами разработки, тестирования и производства. Когда команды проводят много времени в борьбе с непредвиденными «пожарами», общая производительность снижается, а риск выгорания возрастает.

DevOps-услуги: https://efsol.ru/promo/devops.html

🔥 Теперь маршрутные листы можно отправлять курьеру через Телеграм!

К нам обратился клиент с такой задачей — требовалось реализовать функцию отправки маршрутного листа курьеру через Телеграм. Использовать для этого нужно заранее установленный шаблон, маршрутные листы должны быть в формате PDF.

👉 Как выполнили?

В сервисе по автоматизации доставки Delans теперь есть возможность отправки маршрутного листа путем нажатия на кнопку "Отправить в Телеграм". В чат с курьерами отправляются сообщения PDF-формата с указанием в заголовке ФИО курьера, которому адресован маршрут.

Более подробно о сервисе: https://efsol.ru/products/delans.html

🔥 Переход SAP → 1С:ERP. Пора действовать!

Преимущества перехода на решение 1С:ERP:

- гарантия доступности обновлений и поддержки от разработчика.
- экономия на цене лицензий ПО.
- экономия на поддержке и масштабировании.
- более быстрое внедрение.
- гибкость платформы.
- ориентация на российский рынок.
- проще найти команду поддержки и разработки.

Сложности перехода с SAP на 1С:ERP:

- требуется компетентная команда.
- сложная адаптация методологии SAP под нюансы 1С.
- требуется найти поставщика облачной инфраструктуры под 1С:ERP, если SAP размещалась в облаке, либо закупить серверное оборудование для организации своей площадки.

Услугу перехода с SAP на 1С:ERP лучше заказывать у компании, которая имеет большой опыт внедрения 1С:ERP, в т.ч. миграции с других систем.

👉 На базе провайдера облачных услуг EFSOL Oblako, можно получить готовую облачную инфраструктуру для размещения 1С:ERP и разработки проекта перехода с SAP: https://efsol.ru/promo/arenda-erp.html
👉 Также мы готовы оказать помощь в реализации проекта перехода.

🔥 Ответы на популярные вопросы по переходу с 1С:ERP/1С:КА 2.4 на 2.5 - честно и без цензуры

В апреле 2022 года фирма 1С прекратила поддержку конфигураций 1C:ERP и 1С:Комплексная автоматизация версии 2.4, тем самым «заставив» пользователей перейти на версию 2.5.

Итак, к вопросам.

👉 Какой экономический эффект мы получим после обновления?

Переход с 2.4 на 2.5 лучше расценивать как работу с рисками, чем улучшение программы. Со слов разработчика, изменили архитектуру решения и «работали над быстродействием». На практике разницу пока не ощутили, но расширения и доработки приходится «адаптировать», а кое-где и вовсе разрабатывать заново. Это все время и деньги клиентов. К сожалению, экономический эффект посчитать не удалось. т.к. это тоже затратное мероприятие, на которое нужно выделять ресурсы.

👉 Какой функционал добавили?

Основные улучшения в блоке «Производство»: авторезервирование полуфабрикатов, автоматический подбор спецификаций и их настройка, АРМ сотрудника отдела планирования и др. Также появились возможность отслеживать оригиналы бумажных документов, укомплектовывать и разъединять ОС, управлять затратами НИОКР и др. Обновлений функционала много, они небольшие и все приятные.

👉 Какие основные сложности в переходе?

Изменение данных. Выявлены случаи, когда после обновления не сходились данные в регистрах и бухгалтерском учете. Хотя причиной этого стали не совсем верные действия пользователя, но на предыдущих версиях таких проблем не наблюдалось. Также иногда «слетало» закрытие периода, что связано с нововведениями в производстве и оприходовании ТМЦ. Даже при установленном «запрете редактирования периода» программа требовала пересчета себестоимости, и после закрытия ОСВ не совпадала с версией до обновления. Хотя причиной этих инцидентов и были не совсем корректные действия пользователей (меняли настройки системы в процессе работы), но на предыдущих версиях таких ситуаций не наблюдалось. Решение: корректировки записей регистров, корректировки отчетности и подача уточненок.

Технические сбои. Операция обновления ресурсоемкая. Процедуры реструктуризации и обработки данных в информационной базе после обновления могут занимать более 10 часов. Если рабочий сервер «слабый», система останавливается по критической ошибке. Решение: чистим место на сервере, выполняем операции на мощном железе и терпеливо ждем.

Проблемы с доработками. Архитектура решения сильно изменилась:
- Появились изменения в учетных регистрах: регистр по остаткам заменен на регистр распределение запасов; в регистрах взаиморасчетов с поставщиками и клиентами измерение заказа заменено на объект расчетов.
- Изменены либо убраны реквизиты объектов.
- Изменены типовые процедуры по работе с печатными формами и заполнению табличной части из файла.
- Доработки и расширения сначала нужно запустить с помощью программиста, а потом адаптировать, привлекая пользователей для теста.

👉 Какая трудоемкость реализации?

Минимальное время, которое мы затрачивали на переход - 20 часов. Максимальное - 230 часов. Все индивидуально и зависит от качества ведения данных и количества доработок и расширений.

К сожалению, невозможно сопоставить и описать весь полученный опыт при переходе на версию 2.5. Больше знают наши специалисты - оставляйте вопросы и мы обязательно на них ответим: https://efsol.ru/products/erp.html

🔥 Netbox — документируем сеть

Сегодня хотим рассказать о системе NetBox, которую мы внедрили у себя для документирования хостинговой инфраструктуры. NetBox - бесплатная open source система, которая нам показалась наиболее интересной среди аналогичных бесплатных систем.

👉 Что нам нужно было систематизировать:

- Графическое отображение размещения оборудования в стойках.
- Состав серверов, в том числе протоколирование изменения комплектующих в процессе эксплуатации.
- Статус тех или иных серверов — входят ли они в состав облака или выделены персонально под клиента.
- MAC-адреса серверов и схема сетевой коммутации.

Ранее часть этих задач мы решали с помощью Excel, но 4 пункт нормально поддерживать в нем было невозможно, да и с протоколированием изменений были сложности.

В свою очередь NetBox позволяет автоматически считывать MAC-адреса с введенных в систему серверов, что очень удобно для сетевых инженеров. NetBox имеет удобную систему протоколирования изменений каждого узла. Графическое отображение размещения и связанности всех узлов также на высоте в этой системе. Ну и вишенкой на торте можно назвать наличие API у NetBox, что позволяет автоматизировать изменение узлов через Тикет-систему и, в перспективе, автоматически добавлять виртуальные и физические сервера, при использовании разворачивания и удаления их по методу "инфраструктура как код".

Можно констатировать, что система полностью удовлетворяет нашим запросам, имеет задел для расширения функционала.

👉 Нужен облачный хостинг? Добро пожаловать в EFSOL Oblako: https://efsol.ru/cloud/

🔥 Какой вариант кэш-пулинга выбрать?

Сash-pooling или Консолидация денежных средств группы компаний — это метод управления денежными средствами, используемый корпоративной группой, состоящей из нескольких организаций.

Использование кэш-пулинга позволяет избежать лишних расходов на банковское обслуживание и уплаты процентов за использование денежных средств банка.

👉 Существует несколько методов объединения денежных средств (ДС):

- физическое;
- виртуальное;
- смешанное.

Ниже опишем преимущества и недостатки физического кэш-пулинга, когда в автоматическом режиме все остатки ДС зачисляются на один счет компании.

👉 Преимущества:

- Контроль над движением и остатками ДС компании.
- Самые выгодные условия привлечения займов и размещения временно свободных ДС (по сравнению с другими методами объединения ДС).
- Сокращение затрат на банковское обслуживание.

👉 Недостатки:

- Необходимость детального планирования ликвидности.
- Дополнительные затраты на ИТ-инфраструктуру для поддержки инструмента управления ДС.
- Большое количество договоров между участниками.

С преимуществами и недостатками виртуального и смешанного кэш-пулинга можно ознакомиться в нашей обзорной статье: https://efsol.ru/promo/cash-pooling.html.

А как автоматизировать и запустить процесс кэш-пулинга — готовы рассказать наши консультанты!