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