Қосылған өнім оны қоршаған инженерлік жұмыстар аяқталғанға дейін әлдеқайда бұрын дайын болып көрінуі мүмкін. Прототип тұрақты, деректер бұлтқа жетеді, қолданба дұрыс мәндерді көрсетеді және құрылғылардың алғашқы партиясы пайдаланушылардың қолында. Сол кезде сервер әлі де команда әрбір құрылғыны жеке-жеке білетіндей қарапайым болуы мүмкін. Қамтамасыз етуді сценарий арқылы өңдеуге болады, конфигурация өзгерістерін қолмен жасауға болады, ал егер бірдеңе істен шықса, инженер әдетте мәселені тікелей анықтай алады.
Содан кейін ол нақты әлемде өмір сүре бастауы керек. Екінші аппараттық нұсқа пайда болады. Кейбір тұтынушылар әлі де бірінші нұсқаны пайдаланып жатыр. Микробағдарлама нұсқалары әртүрлі бола бастайды. Басқа тұтынушы немесе нарық үшін жаңа конфигурация қажет, ал ескі құрылғыларға жаңартулар мен қолдау қажет.
Ештеңе міндетті түрде бұзылмайды. Құрылғының артындағы бағдарламалық жасақтама өзінің өмірлік циклін алды.
Бұл ауысуды байқамай қалу оңай, себебі прототип мінсіз жұмыс істей береді. Бірақ бір физикалық өнімнің бірнеше нұсқасы далада бірге өмір сүруге мәжбүр болғаннан кейін, сервер енді тек аппараттық құралдың артындағы инфрақұрылым ғана емес. Ол өнім архитектурасының өзінің бөлігі болады.
Жұмыс істейтін қосылған прототип әлі масштабталатын өнім емес
Прототиптің маңызды міндеті бар: жүйенің басынан аяғына дейін жұмыс істейтінін дәлелдеу. Құрылғы өзінің негізгі функциясын орындайды, микробағдарлама сервермен байланысады, телеметрия қажетті жерге келеді, командалар кері сапар жасайды, ал мобильді немесе веб-интерфейс пайдаланушыға функцияны ашады.
Әдетте, бір жүйенің әртүрлілікті қаншалықты жақсы өңдейтіні дәлелденбеген.
Алғашқы жиырма құрылғының барлығы бірдей микробағдарламаны іске қосуы, бірдей аппараттық нұсқаға сәйкес құрастырылуы және бірдей инженерлермен конфигурациялануы мүмкін. Бұл кезеңде қолмен тіркеу, конфигурацияны тікелей өзгерту немесе шағын бейімдеу сценарийі толығымен орынды болуы мүмкін. Өнім өзін көрсеткенге дейін өндірістік деңгейдегі құралдарды жасау ерте болуы мүмкін.
Масштаб мәселені өзгертеді. Құрылғылар желіден тыс қалады, ауыстырылады, әртүрлі микробағдарламаны іске қосады және әртүрлі тұтынушы конфигурацияларын қажет етеді. Қолдау қызметі ешқашан дұрыс қамтамасыз етілмеген құрылғыны дұрыс конфигурацияланбаған немесе жай ғана қол жетімді емес құрылғыдан ажыратуы керек.
Прототиптік қарыз көбінесе осылай басталады: дұрыс емес шешімнен емес, өнім басқа нұсқаға өткеннен кейін орнында қалатын уақытша шешімнен. Ал бұл өзгерісті көзге көрінетін алғашқы нәрселердің бірі - аппараттық құралдың өзі. Жаңа нұсқа ескісін жай ғана алмастырмайды; ол онымен бірге өмір сүруі керек.
Әрбір аппараттық құралды қайта қарау бағдарламалық жасақтаманың өмірлік циклінде ақаулық тудырады
Жаңа аппараттық нұсқа ескі нұсқаның орнына сирек кездеседі. Іс жүзінде екі нұсқа да, кейде жылдар бойы, қолданыста болады. Өтпелі топтаманы, бірнеше микробағдарлама тармақтарын және тұтынушыға тән конфигурацияларды қоссаңыз, флот бастапқы өнім моделінде көрсетілгеннен тезірек әртүрлі болады.
Бағдарламалық жасақтама деңгейі енді әрбір құрылғыны абстрактілі «құрылғы» ретінде қарастыра алмайды. Ол сол құрылғының не істей алатынын білуі керек.
Жаңартылған тақта басқа сенсорды, байланыс модулін немесе контроллерді пайдалануы мүмкін. Соңғы нұсқа үшін жарамды пәрменді бұрынғы нұсқа қолдамауы мүмкін. Калибрлеу мәндері өзгеруі мүмкін. Конфигурация шектеулері өзгеруі мүмкін. Бір буынға жарамды микробағдарлама пакеті екінші буын үшін қауіпсіз болмауы мүмкін.
Физикалық өнім инженерлері қазірдің өзінде осылай жұмыс істейді. Бірдей көрінетін екі компонент, егер олардың түзетулері, төзімділіктері немесе сипаттамалары әртүрлі болса, бір-бірін алмастыра алмайды. Байланысты өнімдер бағдарламалық жасақтама жағында бірдей мәселе тудырады: платформа физикалық өнімнің қай нұсқасы туралы айтып отырғанын және оған қандай ережелер қолданылатынын түсінудің сенімді жолын қажет етеді.
Бірінші нұсқасында бір калибрлеу процедурасы қолданылатын, ал екіншісінде жаңа сенсор және басқа параметрлер жиынтығы енгізілетін өнімді қарастырайық. Тұтынушы үшін екі құрылғы да бірдей өнім болуы мүмкін, бірақ платформа үшін олар бірдей болуы мүмкін емес.
Егер бұл айырмашылықтар анық көрсетілмесе, олар қолданба логикасына ерекше жағдайлар ретінде еніп кетуге бейім. Бір жұмыс процесі сериялық нөмір диапазонын тексереді. Екіншісі аппараттық құралды генерациялау үшін прокси ретінде микробағдарлама нұсқасын пайдаланады. Үшіншісінде қолдау ескі топтың өрісте басқаша әрекет ететінін анықтағаннан кейін қосылған ерекшелік бар. Бұл түзетулердің ешқайсысы өздігінен аса қауіпті көрінбейді, бірақ бірге олар әрбір болашақ өзгеріс туралы ойлауды қиындатады.
Ескі жабдық сирек жағдайда кесте бойынша жоғалып кетеді. Өнім топтары ең жаңа нұсқаға назар аударады, ал тұтынушылар көбінесе ескі нұсқаларды күткеннен әлдеқайда ұзақ сақтайды. Сондықтан платформа орнатылған база бір ағымдағы күйге келеді деп ойлаудың орнына бірден бірнеше буынға қолдау көрсетуі керек.
Бұл орын алғаннан кейін, аппараттық эволюция және бағдарламалық жасақтаманың өмірлік циклін басқару ажырамас бөлікке айналады. Платформа құрылғының қай жерде екенін және оның онлайн режимінде екенін ғана емес, сонымен қатар оның не екенін, не жұмыс істей алатынын, қалай конфигурациялануы керектігін және қандай өзгерістерді қолдану қауіпсіз екенін білуі керек.
Ал осы сұрақтардың кез келгеніне сенімді жауап бермес бұрын, әрбір құрылғы жүйеге бірізді түрде кіруі керек.
Қолмен инженерия масштабтауды тоқтататын жер - бұл қамтамасыз ету
Автопарк шағын болған кезде жабдықтау қарапайым болып көрінеді: құрылғы жазбасын жасаңыз, сериялық нөмірді енгізіңіз, тіркелгі деректерін жасаңыз, құрылғыны тұтынушыға тағайындаңыз, конфигурацияны қолданыңыз және жалғастырыңыз. Бірнеше ондаған құрылғылар үшін мұның кейбірін қолмен өңдеу әлі де дұрыс таңдау болуы мүмкін.
Дегенмен, өндіріс көлемінде жабдықтау құрылғының сәйкестігі, тіркелгі деректері, меншік құқығы, конфигурация және өмірлік цикл күйінің қиылысында орналасқан. Бейімдеу кезінде жіберілген қате құрылғының зауыттан шыққаннан кейін ұзақ уақыт бойы қалай жұмыс істейтініне және қолдау көрсетілетініне әсер етуі мүмкін.
Электрондық кесте енді орнатылғанға сәйкес келмеуі мүмкін. Ауыстырылатын құрылғы дұрыс емес сәйкестікті мұра етпей, дұрыс тұтынушы байланысын қажет етеді. Зауыттық параметрлерге қалпына келтіру процесте басқа жол жасайды. Орнатушы құрылғыны дұрыс емес тіркелгіге тағайындай алады, бұл оның желіден тыс екенін, дұрыс қамтамасыз етілмегенін немесе жай ғана дұрыс емес конфигурацияны жүктеп жатқанын анықтау үшін қолдауды қалдырады.
Бұл сұрақтарға жауап беру үшін әзірлеушіден дерекқорды тексеру немесе ішкі сценарийді іске қосу талап етілгеннен кейін, процесс өніммен масштабтауды тоқтатады.
Көшіру - тағы бір ескерту белгісі. Әрбір өнім нұсқасы өзінің бейімдеу скриптін, конфигурация құралын немесе орнатушы жұмыс процесін ала бастайды. Бұл айырмашылықтар шағын болып көрінуі мүмкін, бірақ негізгі жауапкершілік бірдей. Қамтамасыз ету белгілі бір құрылғыға бекітілген орнату тапсырмасынан гөрі қайта пайдалануға болатын платформа инфрақұрылымына айналды.
Және бұл сирек қайта пайдалануға болатын жалғыз мүмкіндік.
Платформа қабаты қайта пайдалануға болатын инфрақұрылымға айналуы керек
Бірнеше өнім немесе аппараттық құралдың қайта қаралуы бірдей негізгі қажеттіліктерді бөліскеннен кейін, кейбір бағдарламалық жасақтама мүмкіндіктері өнімге тән болуды тоқтатады. Құрылғының сәйкестендіруі, қамтамасыз ету, қосылым, телеметрия, микробағдарламаны жеткізу, өмірлік цикл күйі, парктің көрінуі және диагностика жақсы мысалдар бола алады. Оларды әрбір жаңа нұсқа үшін қайта құру өнімнің өзін ерекшелендірмей, көбірек код пен көбірек операциялық жолдарды жасайды.
Командалар сирек жағдайда бұл қайталауды жасауға кіріседі. Команда бірдей инженерлік жауапкершілікке айналған бірнеше іске асыруды сақтағанша, әрбір өнімнің айналасында шағын айырмашылықтар жиналады.
Таза шекара - өнім қабатын платформа қабатынан бөлу. Өнім қабатында белгілі бір құрылғыны құнды ететін мінез-құлық, жұмыс процестері, интерфейстер, интеграциялар және домен логикасы бар. Платформа қабаты аппараттық құрал өзгерген кезде де тұрақты болып қалуы керек механиканы өңдейді.
Байланысты өнімдер алғашқы шығарылымынан тысқары шыққан сайын, құрылғыларды қамтамасыз ету, құрылғылардың өмірлік циклін басқару, автопаркті басқару және қолдау құралдары бір реттік жоба мәліметтері емес, ортақ инфрақұрылымға айналады. Кәсіпорындарға арналған IoT PaaS бірнеше өнімдер немесе өнім нұсқалары бойынша қайта пайдалануға болатын платформа қабатын қамтамасыз ете алады, стандартты құрылғылар мен деректерді басқаруды қайта пайдалануға болатын құрылыс блоктары арқылы өңдейді, ал инженерлік топтар өздерінің арнайы күш-жігерін аппараттық құралдарға, жұмыс процестеріне және пайдаланушы тәжірибесіне бағыттайды.
Ортақ негіз әлі де нақты өнім айырмашылықтарына орын қалдыруы керек. Жаңа құрылғыға басқа деректер моделі, конфигурация ағыны, интеграция немесе басқару логикасы қажет болуы мүмкін, және бұл айырмашылықтарды енгізу оңай болып қалуы керек. Мақсат - әрбір айырмашылықты басқа құрылғы тізіліміне, телеметрия құбырына, қамтамасыз ету механизміне немесе автопаркті басқару құралдары жиынтығына сүйретпеу.
Платформа команда бірінші өнімді жасап жатқанда үстіңгі қабат сияқты көрінуі мүмкін, ал екінші немесе үшінші өнімді жасағанда актив сияқты көрінуі мүмкін. Жалпы операциялық механика орнатылғаннан кейін, жаңа нұсқа команда өнімнің қалған қызмет ету мерзімі ішінде сақтауы керек басқа сервермен бірге келудің орнына жұмыс негізін мұра ете алады.
Өнім іс жүзінде басқаша болатын жерде арнайы инженерияны сақтаңыз
Қайта пайдалануға болатын платформа қосылған өнімдерді жалпылама етпеуі керек. Оның міндеті - дифференциацияны тудырмайтын бөліктерден қайталанатын инженерияны алып тастау.
Тапсырыс бойынша күш салу әлі де құрылғының жұмыс істеуіне, доменге тән логикаға, жұмыс процестеріне, пайдаланушы тәжірибесіне, мамандандырылған интеграцияларға және белгілі бір өнімнің физикалық әлеммен өзара әрекеттесу тәсіліне қатысты. Дәл осы салаларда инженерлік таңдаулар бір өнімді екіншісінен маңызды түрде жақсырақ ете алады.
Айналадағы жұмыс істейтін сантехника сирек бірдей қарастырылуға лайық. Бір машинаның негізгі нұсқасы мен өнеркәсіптік нұсқасы әртүрлі сенсорларды, басқару элементтерін және интерфейстерді қажет етуі мүмкін, бірақ олар құрылғыларды анықтаудың, микробағдарлама нұсқаларын бақылаудың немесе автопаркті басқарудың бөлек тәсілдерін қажет етпеуі керек.
Мен инженерлердің сол уақытты команданың басқа өнімге арналған механикасын қайта құрудан гөрі өнімнің далада қалай жұмыс істейтінін жетілдіруге жұмсағанын қалаймын. Ортақ іргетас арнайы инженерияның мүмкіндіктерін азайтпайды; ол бұл күш-жігерді инфрақұрылымның жұтып қоюынан қорғайды.
Нағыз сынақ команда екінші өнімді шығара бастаған кезде келеді.
Жақсы платформа келесі өнімді біріншісіне қарағанда жеңілдетеді
Егер екінші өнім бірінші өніммен бірдей платформалық жұмысты қажет етсе, іс жүзінде өте аз нәрсе қайта пайдаланылған.
Жаңа нұсқа операциялық модельдің өзгермеген бөліктерін мұра ете алуы керек: қамтамасыз ету ағындары, сәйкестік, өмірлік цикл механикасы, флот құралдары, микробағдарламалық жасақтама процестері, қолдаудың көрінуі және жалпы интеграциялар. Содан кейін инженерлік күш-жігер негізді қайта құрудың орнына айырмашылықтарға - мүмкін жаңа сенсорлық пакетке, басқа басқару жұмыс процесіне немесе тұтынушыға тән интеграцияға - жұмсалады.
Жаңа аппараттық буын сол идеяны көбірек қысымға ұшыратады. Ескі құрылғылар далада белсенді болып қалған кезде оның мүмкіндіктері айтарлықтай өзгеруі мүмкін. Жетілген платформа команданы тұтынушылар әлі де бір өнім тұқымдасы ретінде қабылдайтын екі бөлек платформа стегін сақтауға мәжбүрлемей, екеуін де қолдай алады.
Мұның ешқайсысы бірыңғай монолитті серверді қажет етпейді. Әртүрлі өнімдер әлі де айқын сәулеттік шекараларды қажет етуі мүмкін. Маңыздысы - дәлелді себепсіз бірдей инженерлік жауапкершілікті екінші рет жүзеге асырудан аулақ болу.
Міне, сол кезде платформа жинақталған шығындардың орнына активке айналады. Қолдау көрсетуде түсінуге болатын параллель құралдар аз, шығарылымдар тұрақты жолдармен жүреді, ал басқа өнімді қосу компания шексіз мұраға алатын басқа сервердің орнына бақыланатын кеңейтімге айналады.
Платформаны өнім архитектурасының бөлігі ретінде қарастырыңыз
Физикалық өнімдер қайта қарауларды, қызмет көрсетуге жарамдылықты, өндіріске жарамдылықты және болашақтағы өзгерістерді ескере отырып жасалған. Байланысты өнімдер бағдарламалық жасақтама жағынан да дәл осындай тәртіпті қажет етеді.
Бірінші серверлік жүйе уақытша болуы мүмкін. Бірінші қамтамасыз ету скрипті немесе қолдау құралы да солай болуы мүмкін. Мұнда ешқандай қателік жоқ. Мәселелер өнімнің өзі дами берген кезде, уақытша механика тыныш тұрақты архитектураға айналған кезде басталады.
Сол кезде қосылған өнім енді тек аппараттық құрал, микробағдарлама және қолданба ғана емес. Ол сондай-ақ әрбір құрылғыны анықтайтын, оның мүмкіндіктерін түсінетін, дұрыс конфигурацияны қолданатын, жаңартуларды қолдайтын және командаларға жеткізілімнен кейін бірнеше жылдан кейін мәселелерді анықтауға көмектесетін инфрақұрылымға байланысты.
Бұл қабат өнім архитектурасы ретінде қарастырылғаннан кейін, бөлу айқынырақ болады: стандартты механика қайта пайдалануға жарамды болып қалады, ал арнайы жұмыс бір өнімді немесе өнім тұқымдасын екіншісінен нақты ажырататын нәрсеге бағытталады.
Ең мықты платформа тек бірінші қосылған өнімді мүмкін ететін платформа ғана емес. Бұл инженерлік топқа әрқашан жаңа бэкендті мұра етпей, екінші, үшінші және төртінші платформаларды құруға мүмкіндік беретін платформа.
