IT-стандарты *

Неважно, в какой сфере вы работаете: backend-разработчик, frontend, архитектор БД, системный аналитик, тестировщик или кто-то еще. А может, вы только ищете работу в IT? Или просто интересуетесь, как устроен цифровой мир. Эта статья - возможность освежить в памяти базовые концепции программирования, подготовиться к собеседованию (ведь вопрос про CRUD-операции может прозвучать не напрямую, но почти всегда скрыт в других задачах или кейсах) или просто понять, как устроены ваши любимые приложения.

Вопрос на миллион: Знаете ли вы, что общего между созданием поста в Нельзяграм, покупкой на Ozon и обновлением резюме на hh.ru?

Ответ прост: в их основе лежат четыре базовые операции, скрытые за аббревиатурой CRUD. И да, эти операции — первая ступень к пониманию того, как работают современные API.

Меня зовут Евгений Котухов, я эксперт по внедрению и оптимизации ITSM/ITAM решений, официальный технологический партнер SimpleOne с 10-летней экспертизой в автоматизации ИТ-процессов. Реализовал десятки ESM-проектов для компаний госсектора, энергетики, торговли и финансов.

В этом материале я хочу поделиться опытом, как выбрать ITSM/ESM систему и что, на мой взгляд, нужно учесть. За 10+ лет внедрений я видел, как компании выбирают решения и мне есть, что сказать по этому поводу.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. Сегодня я расскажу о ноябрьской встрече Международного комитета по стандартизации языка программирования C++, в которой принимал активное участие. Это была первая из встреч, связанных с «полировкой» C++26. Другими словами, новые фичи C++ пока не появятся — комитет должен только проработать замечания всех стран-участников, включая наши замечания от России.

Однако от плана немного отступили и втащили некоторые новинки как ответы на пожелания участников комитета: std::integer_sequence оброс новой функциональностью, а std::format научился в constexpr.

Помимо этого, поправили множество багов, перековыряли связку Hardening + Contracts, внесли улучшения во многие части стандартной библиотеки.

Всем привет, меня зовут Рома, я работаю во ВкусВилле, руковожу портфелем ИИ-проектов. Пишу про продукты и управление проектами у себя на канале: https://t.me/gde\_value. Сегодня расскажу, как спор между командами привел нас к пересмотру методов планирования рабочей недели. 

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

Недавно обсуждал это с тимлидом из Ozon. Мы крутились вокруг темы эффективного количества рабочих часов, и ближе к концу он вкинул фразу: «Ну, сорокачасовая неделя ведь не зря придумана; наверное, кто-то исследовал и доказал, что так эффективнее всего». Эта фраза зацепила. Она звучит как успокаивающий миф, как будто есть универсальная «магическая» цифра, и если не выходить за её пределы, то и продуктивность, и здоровье в порядке. Но внутренне я вижу другое: одни люди успевают сокрушительный объём за те же часы, в которых другие тонут в бесконечных переключениях и «шуме».

Управление секретами — одна из наиболее критичных задач в корпоративной ИТ-инфраструктуре. От того, насколько надежно и централизованно хранятся ключи API, пароли, токены и сертификаты, зависит не только безопасность сервисов, но и устойчивость всего бизнеса.

С ростом популярности отечественных решений особое внимание уделяется возможности интеграции с российскими СУБД. В этом материале команда «Онланты» делится опытом тестирования StarVault — системы управления секретами — в связке с Postgres Pro в лабораторных условиях.

Цель эксперимента — проверить, насколько Postgres Pro подходит для использования в качестве внешнего хранилища StarVault, оценить производительность и устойчивость конфигурации, а также проработать сценарии аварийного восстановления.

Low‑code платформы давно обещают скорость разработки, но что делать, когда вы упираетесь в их ограничения? Бизнес сталкивается с выбором: смириться с рамками Low‑code или переходить на дорогую заказную разработку.

В статье рассматривается гибридный подход на примере платформы SimpleOne, объединяющий преимущества Low‑code со свободой Pro‑code инструментов. Вы узнаете, как в одной среде бизнес‑аналитики могут настраивать типовые процессы через интерфейс, а разработчики — писать код для нестандартных задач.

✔ Разберем архитектуру платформы, построенную по принципу последовательного расширения возможностей
✔ Покажем встроенные Pro‑code инструменты: JavaScript‑скрипты, кастомные виджеты и REST API коннекторы
✔ Приведем примеры реальных кейсов от компаний, которые вышли за рамки стандартной функциональности

Узнайте, как объединить скорость Low‑code с гибкостью Pro‑code и избавиться от технологических разрывов в ваших ИТ‑проектах!

Дисклеймер: Для кого эта статья? Для руководителей малого и среднего бизнеса, которые не хотят терять деньги из-за сбоев в 1С. Если вы ищете способ застраховать свой бизнес от рисков и выбрать надежного партнера по сопровождению — здесь вы найдете ответы.

Представьте, что 1С — это ваш рабочий автомобиль. Вы же не станете ждать, пока у него на полном ходу откажут тормоза, чтобы поехать в сервис? Вы регулярно проходите техосмотр, потому что это нормально и гарантирует безопасность. С 1С — то же самое. Профессиональное сопровождение — это и есть тот самый «техосмотр», который защищает вас от «аварий»: внезапных сбоев, зависаний и, не дай бог, потери данных.

Продолжая аналогию, сопровождение — это как КАСКО. Вы платите небольшую сумму ежемесячно, чтобы в случае «ДТП» — будь то сбой после обновления, уход ключевого сотрудника или простая ошибка пользователя — не платить из своего кармана сотни тысяч рублей за срочный ремонт и не терять дни и недели работы.

Дисклеймер: Это не пошаговый гайд «сделай сам», а честный рассказ о годовом пути, ошибках и находках. Возможно, он вдохновит кого-то из вас на свои проекты — будем рады обратной связи!

Производительность Low-code платформы — один из самых спорных вопросов для enterprise-сегмента. Интерпретация настроек «на лету» создает дополнительную нагрузку по сравнению с готовыми решениями, но дает бизнесу гибкость и возможность быстро менять процессы. Работая с крупнейшими заказчиками, мы сделали производительность стратегическим приоритетом и сейчас продолжаем развивать платформу под требования больших компаний. С 2023 года производительность SimpleOne выросла с 56 тысяч до миллиона пользовательских обращений в месяц — это результат системной работы над архитектурой платформы.

Рассказываем о нашем пути и архитектурных решениях, которые позволили увеличить производительность Low-code платформы.

Мы продолжаем нашу серию статей, посвящённых фундаментальным концепциям разработки. Сегодня мы поговорим о проверенных практиках, которые помогают разработчикам избегать распространённых ошибок и работать эффективнее. Мы разберём принципы SOLID, а также парадигмы YAGNI, DRY и KISS, которые особенно актуальны в объектно-ориентированном программировании.

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

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

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

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

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

Меня зовут Евгений Котухов, я эксперт по внедрению и оптимизации ITSM/ITAM решений, официальный технологический партнер SimpleOne с 10-летней экспертизой в автоматизации IT-процессов. Реализовал десятки ESM-проектов для компаний госсектора, энергетики, торговли и финансов. Специализируюсь на быстрых внедрениях полного цикла с запуском от 2 месяцев - от аудита процессов до рабочего решения, включая сложные интеграции с корпоративными системами. Обладаю опытом руководства командой, внедрения новых методологий и повышения качества IT-услуг через оптимизацию процессов и ITSM-систем.

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

Всем привет! Меня зовут Саша, работаю ведущим аналитиком в Озон Банке. По мотивам доклада на онлайн-дне МатеМаркетинга'25 было решено написать данную статью, пересказывающую основные идеи доклада о семплировании Томпсона.

Привет! Меня зовут Женя Орлов, я руковожу NLP-разработкой в red_mad_robot. Мы экспериментируем с мультиагентными системами и изучаем, как LLM ведут себя в разных архитектурах. В процессе накопилось много наблюдений и рабочих инсайтов — хочу поделиться тем, что помогает нам при проектировании AI-агентов. 

В последнее время внимание инженеров и исследователей привлекают агентные архитектуры — системы, где LLM координирует работу внутренних инструментов и других моделей. Разберём два основных подхода к построению агентных систем. 

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

ITSM-система помогла навести порядок в процессах, но не дала ответа на главный вопрос: сколько на самом деле стоит порядок и можно ли тратить меньше без потери качества?

Меня зовут Евгения Асоскова, я владелец продукта SimpleOne ITAM. Давайте поговорим о том, почему компаниям с внедрённой ITSM-системой целесообразно автоматизировать управление ИТ-активами и как это усилит возможности бизнеса.

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

Как это работает? Как обычный пользователь может изолировать процессы, создавать сетевые пространства и управлять хранилищем без единой привилегии? Давайте разберемся, что скрывается за rootless Podman :)

Гордон Мур 19 апреля 1965 года сказал приблизительно следующее: в кристаллах процессоров становится вдвое больше транзисторов каждые 2 года. По крайней мере какое‑то время это правило выполняется. С оговоркой, что сначала он назвал год, а потом скорректировал до двух, но со второй попытки его слова более не менялись.

Для обывателя это звучит как «компьютеры становятся вдвое мощнее», что, впрочем, недалеко от правды.

Тезисы статьи:

1. Компьютеры с мощностью, характерной для 2030 года выпуска, могли бы теоретически существовать и в 2020, и в 2010, и даже в 1970 году.

2. Если закинуть немного кремния, металлических руд, кислот, щелочей и углеводородов в баночку, и хорошенько её потрясти над доменной печью, с ненулевой вероятностью может оказаться, что, когда мы закончим трясти — в банке окажется iPhone 8 Plus.

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

4. Так как радио уже мертво на Земле, оно и подавно мертво на других планетах. Для поисков электромагнитных аномалий логичнее использовать TEMPEST‑эффект.

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

С одной стороны, программные ЦОДы значительно ускоряют бизнес-процессы и упрощают управление инфраструктурой. С другой стороны, российские регуляторы (ФСТЭК России, ФСБ и Росстандарт) предъявляют жесткие требования к обеспечению безопасности, надежности и соответствия национальным стандартам, особенно в сферах, затрагивающих критическую информационную инфраструктуру и обработку персональных данных.

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

Меня зовут Дмитрий Гоголев, я — директор по развитию облачной платформы Cloudlink в Orion soft, и моя цель — помочь читателям разобраться, как грамотно и без лишних затрат обеспечить соответствие российскому законодательству, не жертвуя при этом преимуществами современных технологий.

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

Техническая архитектура предприятия (ETA - Enterprise Technical Architecture) – это совокупность программно-аппаратных средств, методов и стандартов, поддерживающих эффективное функционирование приложений, и обеспечивающих стабильность, масштабируемость, безопасность.

С другой стороны, можно констатировать, что основное предназначение технологической(технической) архитектуры – это обеспечение надежных ИТ-сервисов(услуг), предоставляемых в рамках всего предприятия в целом и координируемых централизованно ИТ службой.

«Ну ты же компьютерщик!» — многим из ИТ-сферы знакома эта фраза из прошлого. Ей обосновывали, почему именно вы должны сделать почти всё: от настройки принтера до разработки и тестирования систем.

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

На практике это порождает новую версию старой фразы: «Ты же архитектор? Вот и придумай, как это сделать, собери требования, спроектируй данные и проверь, чтобы влезло в бюджет».

В этой статье я разберу роли этапа проектирования ИТ-решений и покажу инструмент для формирования команды, которая совместной работой обеспечивает качественные требования. Иными словами, постараюсь ответить на вопрос: как побороть разрозненность требований через чёткое распределение ролей и ответственности.