01SYSTEM THINKING
Почему IT-проект стоит начинать не со стека
Выбор технологий важен, но он не является первым архитектурным решением. Если начать с базы данных, фреймворка или способа развертывания до того, как понятен сам процесс, проект быстро начинает обслуживать выбранные инструменты вместо задачи бизнеса.
Я обычно начинаю с карты процесса: кто создаёт данные, где они меняются, что является источником истины, какие операции критичны по времени, что может происходить автономно и что должно пережить отказ отдельного компонента. После этого становятся видны реальные границы будущей системы.
Тогда технологический стек становится следствием требований. Это уменьшает количество случайных зависимостей, делает обновления предсказуемее и позволяет обсуждать архитектуру на языке результата: время операции, стоимость сопровождения, доступность, восстановление и возможность дальнейшего развития.
02OFFLINE-FIRST
Offline-first — это не режим «без интернета»
Для полевых, геоинформационных и распределённых систем возможность открыть приложение без соединения — только самая заметная часть задачи. Настоящая архитектурная сложность начинается после того, как одна и та же сущность может измениться в двух независимых репликах.
Нужно заранее определить идентификаторы объектов, версии, журнал изменений, правила синхронизации и то, какие конфликты допустимо разрешать автоматически. Не менее важно уметь показать пользователю, почему две версии отличаются и какое решение будет принято.
Поэтому offline-first лучше рассматривать как свойство модели данных и жизненного цикла проекта, а не как дополнительный режим интерфейса. Если это заложено с самого начала, система способна работать в нестабильной сети без потери управляемости и без скрытого разрушения данных.
03PRIVATE COMMS
Своя коммуникационная инфраструктура: что важно кроме установки сервера
Развернуть сервер сообщений — сравнительно небольшая часть корпоративной коммуникационной системы. В production появляются вопросы идентификации пользователей, клиентских приложений, голосовых и видеосценариев, хранения данных, резервного копирования, мониторинга и обновлений.
Отдельный слой — миграция. Перенос пользователей, комнат, истории сообщений и вложений требует фиксировать исходное состояние, разделять работу на контролируемые партии и уметь проверить результат до перехода всей организации.
Ценность собственного коммуникационного контура возникает не из факта установки программного обеспечения, а из контроля над данными и эксплуатацией. Организация понимает, где находится информация, как восстанавливается сервис, кто управляет доступом и каким образом система будет развиваться дальше.
041C / OPERATIONS
1С — это не только конфигурация: устойчивость начинается с инфраструктуры
Проблемы 1С нередко начинают искать внутри прикладной конфигурации, хотя реальная причина может находиться на другом слое: ресурсы Linux-сервера, параметры PostgreSQL, дисковая подсистема, фоновые задания, блокировки, сеть или конкретное рабочее место.
Поэтому сервер 1С я рассматриваю как production-систему целиком: сервер приложений, база данных, резервное копирование, журналы, обновления, контроль ресурсов и клиентские рабочие места должны быть частью одного эксплуатационного контура.
Такой подход позволяет сначала измерить, где именно возникает ограничение, и только после этого менять систему. В результате сопровождение становится предсказуемее, восстановление — проверяемым, а рост нагрузки не превращается в последовательность случайных настроек.
