Холбогдсон бүтээгдэхүүн нь инженерчлэл дуусахаас өмнө дууссан мэт харагдаж болно. Туршилтын загвар нь тогтвортой, өгөгдөл нь үүлэн технологид хүрч, апп нь зөв утгыг харуулж, төхөөрөмжүүдийн эхний багц аль хэдийн хэрэглэгчдийн гарт байна. Энэ үед арын хэсэг нь баг бараг бүх төхөөрөмжийг нэг бүрчлэн мэдэхэд хангалттай энгийн байж магадгүй юм. Нөөцийг скриптээр зохицуулж, тохиргооны өөрчлөлтийг гараар хийж болох бөгөөд хэрэв ямар нэгэн зүйл ажиллахгүй бол инженер ихэвчлэн асуудлыг шууд мөрдөж чаддаг.
Дараа нь энэ нь бодит ертөнцөд амьдарч эхлэх ёстой. Хоёр дахь техник хангамжийн хувилбар гарч ирнэ. Зарим хэрэглэгчид эхний хувилбарыг ашигласаар байна. Програм хангамжийн хувилбарууд зөрж эхэлдэг. Өөр хэрэглэгч эсвэл зах зээлд шинэ тохиргоо шаардлагатай байгаа бол хуучин төхөөрөмжүүдэд шинэчлэлт, дэмжлэг шаардлагатай хэвээр байна.
Төхөөрөмжийн ард байгаа програм хангамж нь өөрийн гэсэн амьдралын мөчлөгтэй болсон.
Энэ шилжилтийг алгасахад амархан, учир нь туршилтын загвар нь төгс сайн ажиллаж чаддаг. Гэхдээ нэг ижил физик бүтээгдэхүүний олон хувилбарууд салбарт зэрэгцэн орших ёстой болсны дараа арын хэсэг нь зөвхөн техник хангамжийн ард байгаа дэд бүтэц байхаа больсон. Энэ нь бүтээгдэхүүний архитектурын өөрийнх нь нэг хэсэг болдог.
Ажиллаж байгаа холбогдсон прототип нь өргөтгөх боломжтой бүтээгдэхүүн биш байна
Прототип нь чухал үүрэг гүйцэтгэдэг: систем эхнээсээ төгсгөл хүртэл ажилладаг гэдгийг батлах. Төхөөрөмж нь үндсэн үүргээ гүйцэтгэдэг, програм хангамж нь арын хэсэгтэй холбогддог, телеметр нь байх ёстой газраа ирдэг, командууд буцах аяллыг хийдэг, гар утас эсвэл вэб интерфэйс нь хэрэглэгчдэд функцийг нээж өгдөг.
Энэ нь ихэвчлэн нотлогдоогүй зүйл бол ижил систем олон янз байдлыг хэр сайн зохицуулдаг явдал юм.
Эхний хорин төхөөрөмж бүгд ижил програм хангамж ажиллуулж, ижил техник хангамжийн хувилбараар бүтээгдэж, ижил инженерүүдээр тохируулагдаж болно. Энэ үе шатанд гараар бүртгүүлэх, тохиргоог шууд өөрчлөх эсвэл жижиг хэмжээний дасан зохицох скрипт хийх нь бүрэн ухаалаг хэрэг байж болно. Бүтээгдэхүүн өөрийгөө батлахаас өмнө үйлдвэрлэлийн түвшний хэрэгслийг бүтээх нь эрт байж магадгүй юм.
Масштаб нь асуудлыг өөрчилдөг. Төхөөрөмжүүд офлайн хэвээр байж, солигдож, өөр програм хангамж ажиллуулж, өөр хэрэглэгчийн тохиргоо шаарддаг. Дэмжлэг нь хэзээ ч зөв хангагдаагүй төхөөрөмжийг буруу тохируулсан эсвэл зүгээр л холбогдох боломжгүй төхөөрөмжөөс ялгаж салгах ёстой.
Прототип өр нь ихэвчлэн ийм байдлаар эхэлдэг: буруу шийдвэрээс биш, харин бүтээгдэхүүн шилжсэний дараа байрандаа үлддэг түр зуурын шийдвэрээс эхэлдэг. Мөн энэхүү шилжилтийг нүдэнд тусгадаг хамгийн эхний зүйлсийн нэг бол техник хангамж өөрөө юм. Шинэ хувилбар нь зүгээр л хуучин хувилбарыг орлохгүй; энэ нь үүнтэй зэрэгцэн орших ёстой.
Техник хангамжийн шинэчлэлт бүр програм хангамжийн амьдралын мөчлөгийн асуудал үүсгэдэг
Шинэ техник хангамжийн хувилбар нь хуучин хувилбарыг цэвэр орлох нь ховор байдаг. Практикт хоёр хувилбар хоёулаа заримдаа олон жилийн турш салбартаа хэвээр байдаг. Шилжилтийн багц, хэд хэдэн програм хангамжийн салбар, хэрэглэгчийн онцлогт тохирсон тохиргоог нэмбэл анхны бүтээгдэхүүний загварт санал болгосноос хурдан хугацаанд илүү олон янз болдог.
Програм хангамжийн давхарга нь нэгж бүрийг хийсвэр "төхөөрөмж" гэж үзэхээ больсон. Энэ нь тухайн нэгж юу хийж чадахыг мэдэх шаардлагатай.
Шинэчилсэн самбар нь өөр мэдрэгч, холбооны модуль эсвэл хянагч ашиглаж болно. Хамгийн сүүлийн хувилбарт хүчинтэй командыг өмнөх хувилбар дэмжихгүй байж магадгүй. Тохируулгын утга өөрчлөгдөж болно. Тохируулгын хязгаар өөрчлөгдөж болно. Нэг үед тохиромжтой програм хангамжийн багц нь нөгөө үед аюултай байж болно.
Физик бүтээгдэхүүний инженерүүд аль хэдийн ийм байдлаар ажилладаг. Бараг ижил харагдаж байгаа хоёр бүрэлдэхүүн хэсэг нь засвар, хүлцэл эсвэл техникийн үзүүлэлтүүд нь өөр байвал тэдгээрийг сольж болохгүй. Холбогдсон бүтээгдэхүүнүүд нь програм хангамжийн тал дээр ижил асуудал үүсгэдэг: платформ нь физик бүтээгдэхүүний аль хувилбарын талаар ярьж байгаа, түүнд ямар дүрэм үйлчлэхийг ойлгох найдвартай арга хэрэгтэй.
Эхний хувилбар нь нэг тохируулгын процедурыг ашигладаг бол хоёр дахь хувилбар нь шинэ мэдрэгч болон өөр параметрийн багцыг нэвтрүүлдэг бүтээгдэхүүнийг авч үзье. Үйлчлүүлэгчийн хувьд хоёр төхөөрөмж хоёулаа ижил бүтээгдэхүүн хэвээр байж болох ч платформын хувьд тийм биш байж болно.
Хэрэв эдгээр ялгааг тодорхой харуулаагүй бол тэдгээр нь тусгай тохиолдлууд хэлбэрээр програмын логикт нэвтрэх хандлагатай байдаг. Нэг ажлын урсгал нь серийн дугаарын хүрээг шалгадаг. Өөр нэг нь техник хангамж үүсгэх прокси болгон програмын хувилбарыг ашигладаг. Гурав дахь нь дэмжлэг нь хуучин багц талбарт өөрөөр ажиллаж байгааг илрүүлсний дараа нэмэгдсэн үл хамаарах зүйлийг агуулдаг. Эдгээр засваруудын аль нь ч дангаараа онцгой аюултай мэт харагдахгүй байгаа ч хамтдаа ирээдүйн өөрчлөлт бүрийг тайлбарлахад хэцүү болгодог.
Хуучин техник хангамж хуваарийн дагуу ховорхон алга болдог. Бүтээгдэхүүний багууд хамгийн сүүлийн үеийн хувилбарт анхаарлаа төвлөрүүлдэг бол хэрэглэгчид өмнөх хувилбаруудыг хүлээгдэж байснаас хамаагүй удаан хадгалдаг. Тиймээс уг платформ нь суулгасан суурь нь нэг одоогийн төлөвт нэгдэнэ гэж таамаглахын оронд хэд хэдэн үеийг нэгэн зэрэг дэмжих шаардлагатай болдог.
Ийм зүйл тохиолдсоны дараа техник хангамжийн хувьсал болон програм хангамжийн амьдралын мөчлөгийн менежмент нь салшгүй болдог. Платформ нь зөвхөн төхөөрөмж хаана байгаа, онлайн байгаа эсэхийг төдийгүй юу болохыг, юу ажиллаж болохыг, хэрхэн тохируулах ёстойг, ямар өөрчлөлтүүдийг хэрэгжүүлэхэд аюулгүй болохыг мэдэх шаардлагатай.
Эдгээр асуултын аль нэгэнд нь найдвартай хариулахаас өмнө төхөөрөмж бүр системд тууштай байдлаар орох ёстой.
Хангамж гэдэг нь гарын авлагын инженерчлэл нь масштабыг зогсоох цэг юм
Төхөөрөмжийн нөөц бага байх үед хангамж нь энгийн харагддаг: төхөөрөмжийн бүртгэл үүсгэх, серийн дугаар оруулах, итгэмжлэл үүсгэх, төхөөрөмжийг үйлчлүүлэгчид оноох, тохиргоог хэрэгжүүлэх, цааш үргэлжлүүлэх. Хэдэн арван төхөөрөмжийн хувьд заримыг нь гараар зохицуулах нь зөв сонголт байж болох юм.
Гэсэн хэдий ч үйлдвэрлэлийн хэмжээнд хангамж нь төхөөрөмжийн таних тэмдэг, итгэмжлэл, эзэмшил, тохиргоо болон амьдралын мөчлөгийн төлөвийн огтлолцол дээр байрладаг. Ашиглалтын явцад гарсан алдаа нь үйлдвэрээс гарсны дараа уг төхөөрөмжийг хэрхэн ажиллуулж, дэмжихэд нөлөөлж болно.
Хүснэгт нь бодит суулгасантай тохирохгүй байж магадгүй. Солих төхөөрөмж нь буруу таних тэмдгийг өвлөхгүйгээр зөв хэрэглэгчийн холбоог шаарддаг. Үйлдвэрийн тохиргоонд дахин тохируулах нь үйл явцын өөр замыг бий болгодог. Суулгагч нь төхөөрөмжийг буруу бүртгэлд оноож, офлайн байгаа, буруу хангагдсан эсвэл зүгээр л буруу тохиргоотой эсэхийг тодорхойлох дэмжлэгийг үлдээж болно.
Эдгээр асуултанд хариулахын тулд хөгжүүлэгчээс мэдээллийн санг шалгах эсвэл дотоод скрипт ажиллуулахыг тогтмол шаарддаг бол энэ үйл явц нь бүтээгдэхүүний цар хүрээг нэмэгдүүлэхээ больсон.
Давхардсан байдал нь бас нэгэн анхааруулах тэмдэг юм. Бүтээгдэхүүний хувилбар бүр өөрийн гэсэн onboarding скрипт, тохиргооны хэрэгсэл эсвэл суулгагчийн ажлын урсгалыг олж авч эхэлдэг. Эдгээр ялгаа нь бага мэт санагдаж болох ч үндсэн үүрэг хариуцлага нь адилхан юм. Хангамж нь тодорхой төхөөрөмжид холбогдсон тохируулах даалгавар биш харин дахин ашиглах боломжтой платформ дэд бүтэц болсон.
Мөн энэ нь дахин ашиглах боломжтой болгох шаардлагатай цорын ганц чадвар ховор байдаг.
Платформын давхарга нь дахин ашиглах боломжтой дэд бүтэц болох ёстой
Хэд хэдэн бүтээгдэхүүн эсвэл техник хангамжийн шинэчлэлтүүд ижил үндсэн хэрэгцээг хуваалцсаны дараа зарим програм хангамжийн чадавхи нь бүтээгдэхүүнд хамаарахаа больдог. Төхөөрөмжийн таних тэмдэг, хангамж, холболт, телеметр, програм хангамжийн хүргэлт, амьдралын мөчлөгийн төлөв, флотын харагдах байдал, оношлогоо зэрэг нь сайн жишээ юм. Тэдгээрийг шинэ хувилбар бүрт зориулж дахин бүтээх нь бүтээгдэхүүнийг илүү өвөрмөц болгохгүйгээр илүү олон код, илүү олон үйл ажиллагааны замыг бий болгодог.
Багууд энэхүү давхардлыг бий болгохоор ховорхон гардаг. Баг бүр ижил инженерийн үүрэг хариуцлага болсон хэд хэдэн хэрэгжилтийг хадгалах хүртэл бүтээгдэхүүн бүрийн эргэн тойронд жижиг ялгаа хуримтлагддаг.
Илүү цэвэр хил хязгаар бол бүтээгдэхүүний давхаргыг платформ давхаргаас тусгаарлах явдал юм. Бүтээгдэхүүний давхарга нь тодорхой төхөөрөмжийг үнэ цэнэтэй болгодог зан төлөв, ажлын урсгал, интерфэйс, интеграци болон домэйн логикийг агуулдаг. Платформ давхарга нь техник хангамж өөрчлөгдөх үед ч тогтвортой байх ёстой механикуудыг зохицуулдаг.
Холбогдсон бүтээгдэхүүнүүд анхны хувилбараасаа цааш гарахын хэрээр төхөөрөмжийн хангамж, төхөөрөмжийн амьдралын мөчлөгийн менежмент, флотын менежмент, дэмжлэгийн хэрэгслүүд нь нэг удаагийн төслийн дэлгэрэнгүй мэдээлэл гэхээсээ илүү хуваалцсан дэд бүтэц болж хувирдаг. Байгууллагуудад зориулсан IoT PaaS нь олон бүтээгдэхүүн эсвэл бүтээгдэхүүний хувилбаруудад дахин ашиглах боломжтой платформ давхаргыг хангаж, дахин ашиглах боломжтой барилгын блокуудаар дамжуулан стандарт төхөөрөмж болон өгөгдлийн менежментийг зохицуулж чаддаг бол инженерийн багууд өөрсдийн захиалгат хүчин чармайлтаа техник хангамж, ажлын урсгал, хэрэглэгчийн туршлагад төвлөрүүлдэг.
Нийтлэг суурь нь бодит бүтээгдэхүүний ялгааг гаргах зай үлдээх ёстой хэвээр байна. Шинэ төхөөрөмжид өөр өгөгдлийн загвар, тохиргооны урсгал, интеграци эсвэл хяналтын логик шаардлагатай байж болох бөгөөд эдгээр ялгааг танилцуулахад хялбар хэвээр байх ёстой. Зорилго нь зүгээр л бүх ялгааг өөр төхөөрөмжийн бүртгэл, телеметрийн дамжуулах хоолой, хангамжийн механизм эсвэл флотын удирдлагын хэрэгслүүдийн багцаар чирэхээс зайлсхийх явдал юм.
Баг эхний бүтээгдэхүүнийг бүтээж байх үед платформ нь нэмэлт хэрэгсэл мэт харагдаж, хоёр дахь эсвэл гурав дахь бүтээгдэхүүн дээр хөрөнгө мэт харагдаж болно. Үйл ажиллагааны нийтлэг механизмууд хэрэгжиж эхэлмэгц шинэ хувилбар нь баг тухайн бүтээгдэхүүний ашиглалтын хугацаанд хадгалах ёстой өөр нэг арын хэсэгтэй ирэхийн оронд ажлын суурийг өвлөн авах боломжтой.
Бүтээгдэхүүн нь үнэндээ өөр байгаа тохиолдолд захиалгат инженерчлэлийг хадгалах
Дахин ашиглах боломжтой платформ нь холбогдсон бүтээгдэхүүнийг илүү ерөнхий болгох ёсгүй. Үүний ажил бол ялгаа үүсгэдэггүй хэсгүүдээс давтагдсан инженерчлэлийг арилгах явдал юм.
Захиалгат хүчин чармайлт нь төхөөрөмжийн зан төлөв, домэйнд хамаарах логик, ажлын урсгал, хэрэглэгчийн туршлага, тусгай интеграцчлал, мөн тодорхой бүтээгдэхүүн физик ертөнцтэй хэрхэн харьцдаг зэрэгт хамаарна. Эдгээр нь инженерчлэлийн сонголтууд нь нэг бүтээгдэхүүнийг нөгөөгөөсөө утга учиртайгаар илүү сайн болгож чадах чиглэлүүд юм.
Ойролцоогоор ижил төстэй арга хэмжээ авах ёстой зүйл бол эргэн тойрны ашиглалтын сантехник юм. Нэг машины энгийн хувилбар болон үйлдвэрлэлийн хувилбар нь өөр өөр мэдрэгч, удирдлага, интерфэйс шаардаж болох ч төхөөрөмжүүдийг таних, програм хангамжийн хувилбаруудыг хянах, эсвэл машины паркийг удирдах тусдаа аргуудыг шаардах ёсгүй.
Инженерүүд өөр бүтээгдэхүүний хувьд багийн аль хэдийн бэлтгэсэн механикийг сэргээн засварлахаас илүүтэй тухайн бүтээгдэхүүний талбайд хэрхэн ажиллахыг сайжруулахад цаг зарцуулахыг би илүүд үзэх болно. Хамтын суурь нь захиалгат инженерчлэлийн цар хүрээг бууруулдаггүй; энэ нь тухайн хүчин чармайлтыг дэд бүтцэд залгихаас хамгаалдаг.
Баг хоёрдугаар бүтээгдэхүүнийг эхлүүлэх үед жинхэнэ шалгалт ирдэг.
Сайн платформ нь дараагийн бүтээгдэхүүнийг эхнийхээс илүү хялбар болгодог
Хэрэв хоёрдугаар бүтээгдэхүүн нь нэгдүгээр бүтээгдэхүүнтэй бараг ижил платформ ажиллагаа шаарддаг бол үнэндээ маш бага зүйлийг дахин ашигласан байна.
Шинэ хувилбар нь үйлдлийн загварын өөрчлөгдөөгүй хэсгүүдийг өвлөх боломжтой байх ёстой: хангамжийн урсгал, таних тэмдэг, амьдралын мөчлөгийн механик, флотын хэрэгслүүд, програм хангамжийн процессууд, дэмжлэгийн харагдах байдал, нийтлэг интеграцууд. Дараа нь инженерийн хүчин чармайлт нь суурийг сэргээн босгохын оронд ялгааг - магадгүй шинэ мэдрэгчийн багц, өөр хяналтын ажлын урсгал эсвэл хэрэглэгчдэд зориулсан интеграцийг - олж авдаг.
Шинэ үеийн техник хангамж нь ижил санааг илүү их дарамтанд оруулж байна. Хуучин төхөөрөмжүүд идэвхтэй хэвээр байх үед түүний чадавхи мэдэгдэхүйц өөрчлөгдөж магадгүй юм. Насанд хүрсэн платформ нь багийг хэрэглэгчдийн нэг бүтээгдэхүүний гэр бүл гэж үздэг хоёр тусдаа платформ стекийг хадгалахыг албадахгүйгээр хоёуланг нь дэмжиж чадна.
Эдгээрийн аль нь ч нэг цул арын хэсгийг шаарддаггүй. Өөр өөр бүтээгдэхүүнүүдэд тодорхой архитектурын хил хязгаар шаардлагатай хэвээр байж магадгүй юм. Хамгийн чухал нь сайн шалтгаангүйгээр ижил инженерийн хариуцлагыг хоёр дахь удаагаа хэрэгжүүлэхээс зайлсхийх явдал юм.
Энэ үед платформ нь хуримтлагдсан нэмэлт зардал биш харин хөрөнгө болж хувирдаг. Дэмжлэг нь ойлгоход цөөн зэрэгцээ хэрэгслүүдтэй, хувилбарууд нь илүү тууштай замаар явдаг бөгөөд өөр бүтээгдэхүүн нэмэх нь компанийн тодорхойгүй хугацаагаар өвлөн авдаг өөр нэг арын хэсгийн оронд хяналттай өргөтгөл болдог.
Платформыг бүтээгдэхүүний архитектурын нэг хэсэг гэж үзэх
Физик бүтээгдэхүүнийг засвар, ашиглалтын чадвар, үйлдвэрлэлийн чадвар болон ирээдүйн өөрчлөлтийг харгалзан зохион бүтээсэн. Холбогдох бүтээгдэхүүнүүд нь програм хангамжийн тал дээр ижил сахилга бат шаарддаг.
Эхний backend түр зуурынх байж болно. Эхний хангамжийн скрипт эсвэл дэмжлэгийн хэрэгсэл ч мөн адил. Үүнд ямар ч буруу зүйл байхгүй. Бүтээгдэхүүн өөрөө хөгжсөөр байх зуур эдгээр түр зуурын механикууд чимээгүйхэн байнгын архитектур болж хувирах үед асуудлууд эхэлдэг.
Тэр үед холбогдсон бүтээгдэхүүн нь зөвхөн техник хангамж, програм хангамж, апп байхаа больсон. Энэ нь мөн төхөөрөмж бүрийг тодорхойлж, түүний чадавхийг ойлгож, зөв тохиргоог хэрэгжүүлж, шинэчлэлтийг дэмжиж, багуудад тээвэрлэлтээс хойш олон жилийн дараа асуудлыг оношлоход тусалдаг дэд бүтцээс хамаарна.
Энэ давхаргыг бүтээгдэхүүний архитектур гэж үзсний дараа хуваагдал нь илүү тодорхой болно: стандарт механикууд дахин ашиглах боломжтой хэвээр байх бол захиалгат ажил нь нэг бүтээгдэхүүн эсвэл бүтээгдэхүүний гэр бүлийг нөгөөгөөс нь ялгаж буй зүйлд ордог.
Хамгийн хүчтэй платформ бол зүгээр л эхний холбогдсон бүтээгдэхүүнийг боломжтой болгодог платформ биш юм. Энэ нь инженерийн багт шинэ backend өвлөхгүйгээр хоёр дахь, гурав дахь, дөрөв дэхийг бүтээх боломжийг олгодог платформ юм.
