Технологиийн компаниуд хэрхэн өгөгдөлд суурилсан шийдвэр гаргах вэ?

Технологийн компаниудын хувьд өгөгдөл дээр суурилж (data-driven) шийдвэр гаргах нь зөвхөн хэдэн гоёмсог график харах төдий зүйл биш юм. Энэ нь инженерийн багийн хурд, системийн найдвартай байдал, хэрэглэгчийн туршлага, цаашлаад бизнесийн ашигт ажиллагааг нэгтгэн удирдах стратегийн цөм болдог.

Компанийн үүсгэн байгуулагчид болон Технологи хариуцсан захирлуудын (CTO) хувьд зөн совиндоо найдах эсвэл бусдын жишгийг сохроор дагах нь өрсөлдөөнд ялагдах, нөөцөө үргүй зарцуулах гол шалтгаан болдог.

Өгөгдөлд суурилсан шийдвэр гаргалтын соёлыг нэвтрүүлснээр байгууллага доорх асуултуудад бодит баримттайгаар хариулах боломжтой болно:

• Бүтээгдэхүүний хөгжүүлэлт: Шинээр нэвтрүүлсэн нэмэлт боломж (feature) хэрэглэгчдэд бодитоор үнэ цэнэ өгч байна уу, эсвэл зүгээр л системийн нарийн төвөгтэй техникийн өр нэмэгдүүлж байна уу?
• Хөрөнгө оруулалт ба Зардал: Үүлэн тооцооллын (cloud) зардлын өсөлт нь хэрэглэгчийн өсөлттэй уялдан хэвийн хэмжээнд байна уу, эсвэл архитектурын оновчгүй шийдлээс үүдэж байна уу?
• Инженерийн нөөц хуваарилалт: Баг шинэ боломж хөгжүүлэхэд цаг зарцуулах уу, эсвэл системийн дотоод бүтцийг сайжруулахад (refactoring) төвлөрөх үү?

Эдгээр шийдвэрийг гаргахын тулд зөвхөн эцсийн хэрэглэгчийн дата төдийгүй, дэд бүтцийн лог, гүйцэтгэлийн хэмжүүрүүд (telemetry), санхүүгийн мэдээлэл зэрэг олон эх сурвалжийг нэгтгэн шинжлэх шаардлагатай болдог.

Өгөгдлийг хэрхэн шийдвэр болгон хувиргах нь

Өгөгдөл өөрөө автоматаар үнэ цэнэ бүтээдэггүй. Түүнийг шийдвэр гаргах түвшинд хүргэхийн тулд хэд хэдэн үе шаттай механик процессууд ажилладаг. Эдгээр процессууд нь зөвхөн мэдээлэл зөөвөрлөх бус, бизнесийн хэмжүүрүүдтэй уялдах эргэх холбооны давтамжийг үүсгэх зорилготой.

1. Мэдээлэл цуглуулалт (Ingestion & Telemetry): Аппликейшн, өгөгдлийн сан, дэд бүтцийн түвшнээс бүх төрлийн мэдээллийг (үйл явдлын лог, хэрэглэгчийн үйлдэл, системийн ачаалал зэрэг) найдвартай цуглуулах шат. Энд өгөгдөл алдагдахгүй байх нь чухал.
2. Хувиргалт ба Загварчлал (Processing & Modeling): Түүхий датаг бизнесийн ойлголтуудтай нийцүүлэн цэвэрлэж, нэгтгэх процесс. Энэ шатанд ELT (Extract, Load, Transform) загвар илүү өргөн ашиглагдаж байгаа бөгөөд өгөгдлийн инженерийн багууд бизнесийн логикийг SQL эсвэл код хэлбэрээр тодорхойлдог.
3. Шинжилгээ ба Үйлдэл (Analytics & Action): Бэлэн болсон өгөгдлийг ашиглан автоматжуулсан дохио (alert) үүсгэх, машин сургалтын модельд тэжээл болгон өгөх, эсвэл удирдлагын түвшний тайлан (dashboard) гаргах алхам.

Мэдээллийн урсгалыг оновчтой төлөвлөх талаар илүү дэлгэрэнгүйг Google Cloud-ийн өгөгдлийн амьдралын мөчлөгийн архитектур зэрэг баримт бичгүүдээс харах нь архитектурын ерөнхий зураглал гаргахад тусална.

Өгөгдлийн архитектур ба үйл ажиллагааны загварууд

Архитектурын сонголт нь байгууллагын өгөгдлийн соёл, багийн бүтэц болон зардлын бүтцэд шууд нөлөөлдөг. Технологийн удирдлагууд дараах үндсэн загваруудын хооронд сонголт хийдэг:

• Өгөгдлийн агуулах (Data Warehouse): BigQuery эсвэл Snowflake зэрэг шийдлүүд дээр суурилсан, бүтэцлэгдсэн датанд зориулагдсан төвлөрсөн архитектур. Түүхэн өгөгдөлд дүн шинжилгээ хийх, бизнесийн уламжлалт тайлагналт (BI) хийхэд төгс тохирно. Гэвч бүх датаг нэг стандартад оруулах шаардлагатай тул эхэн үеийн хөгжүүлэлтийн цаг их шаардана.
• Өгөгдлийн нуур (Data Lake): Бүтэцлэгдээгүй эсвэл хагас бүтэцлэгдсэн датаг (зураг, текст, түүхий лог) хямд зардлаар хадгалах боломжтой. Дата анализ болон машин сургалтын (ML) хэрэглээнд тохиромжтой боловч зөв удирдахгүй бол "Өгөгдлийн намаг" (Data Swamp) болох өндөр эрсдэлтэй.
• Data Mesh (Тархсан өгөгдлийн архитектур): Инженерийн багууд томрохын хэрээр төвлөрсөн өгөгдлийн гацалт үүсгэдэг. Энэ асуудлыг шийдэхийн тулд бүтээгдэхүүний баг бүр өөрсдийн домэйн датагаа хариуцан, бусад багуудад "бүтээгдэхүүн" (data as a product) хэлбэрээр үйлчлэх архитектурын болон байгууллагын соёлын шинэ хандлага юм.

Бодит хэрэглээний тохиолдлууд

Технологид суурилсан компаниудад өгөгдлийн тусламжтайгаар шийдвэрлэдэг хамгийн үнэ цэнтэй аргууд доорх байдлаар илэрдэг:

1. Үүлэн тооцооллын зардлын оновчлол (FinOps)

Дэд бүтцийн зардал нь технологийн стартапууд болон байгууллагын хувьд хамгийн том зардлын нэг байдаг. Өгөгдөлд суурилсан багууд `Нэг хэрэглэгчид ногдох дэд бүтцийн өртөг` (Unit Economics) гэх мэт хэмжигдэхүүнийг бодит цагаар хянадаг. Системийн лог болон тооцооны мэдээллийг нэгтгэснээр ашиглагдаагүй нөөцүүдийг унтраах, зөвхөн хэрэгцээт үед нь автоматаар өргөтгөх (auto-scaling) шийдвэрүүдийг хүний оролцоогүйгээр гаргах боломжтой болно.

Илүү нарийвчилсан практик туршлагуудыг FinOps сангийн удирдамж зэрэг нээлттэй эх сурвалжуудаас судалж хэрэгжүүлэх боломжтой.

2. Бүтээгдэхүүний туршилт ба A/B тест

Шинэ функц (feature) хөгжүүлэх нь үргэлж эрсдэл дагуулдаг. Өгөгдөлд тулгуурласан инженерчлэлийн багууд "Feature Flags" ашиглан шинэ боломжийг нийт хэрэглэгчдийн ердөө 5%-д эхэлж нэвтрүүлдэг. Энэ хугацаанд системийн алдааны түвшин (error rate), хариу өгөх хурд (latency), болон хэрэглэгчийн оролцооны датаг цуглуулж шинжилнэ. Хэрэв эерэг үр дүн гарвал 100% болгож, сөрөг нөлөө гарвал шууд буцаах (rollback) шийдвэрийг дата дээр үндэслэн гаргадаг.

3. Инженерийн багийн гүйцэтгэл ба DORA хэмжүүрүүд

Технологийн удирдлагууд хөгжүүлэлтийн багийнхаа бүтээмжийг үнэлэхдээ DORA (DevOps Research and Assessment) хэмжүүрүүдийг ашигладаг. Үүнд:

• Нийлүүлэлтийн давтамж (Deployment Frequency): Хэр олон удаа шинэ код продакшн руу орж байгааг.
• Өөрчлөлтийн хүлээлгийн хугацаа (Lead Time for Changes): Код бичигдэж дууссанаас хойш продакшнд гарах хүртэлх хугацаа.
• Үйлчилгээг сэргээх хугацаа (MTTR): Гэмтэл гарсны дараа хэвийн байдалд оруулах хугацаа.
• Өөрчлөлтийн алдааны түвшин (Change Failure Rate): Оруулсан өөрчлөлтүүдийн хэдэн хувь нь алдаа үүсгэж буй байдал.

Эдгээр датаг CI/CD дамжлагаасаа (pipeline) шууд татан авч шинжлэх нь багийн дотоод гацааг (bottleneck) илрүүлэх бодит хөшүүрэг болдог.

Сул тал, эрсдэл болон хязгаарлалтууд

Бүх зүйлийг датагаар шийдэх оролдлого нь өөрийн гэсэн ноцтой үр дагавруудыг дагуулдаг. Архитектур болон үйл ажиллагааны хувьд дараах эрсдэлүүдийг тооцоолох нь чухал:

• Өгөгдлийн чанар ба Итгэлцэл алдагдах нь: "Garbage in, garbage out" гэдэг зарчим үргэлж үйлчилнэ. Хэрэв дата нь дутуу, буруу, эсвэл шинэчлэгдээгүй байвал удирдлагууд дата багт итгэх итгэлээ алддаг. Итгэлцэл нэг л удаа алдагдсан бол хүмүүс буцаад зөн совингоороо шийдвэр гаргах горим руу шилждэг.
• Далд зардлууд: Бодит цагийн (real-time streaming) өгөгдөл боловсруулах урсгал бүтээх нь маш их өртөгтэй бөгөөд засвар үйлчилгээний хүндхэн дарамт үүсгэдэг. Ихэнх бизнесийн хэрэгцээнд өдөрт нэг удаа шинэчлэгддэг багц (batch) боловсруулалт хангалттай байдаг боловч инженерүүд хэт нарийн төвөгтэй шийдэл (over-engineering) хийх гээд байдаг хандлагатай.
• Нууцлал ба Дагаж мөрдөх журам (Compliance): Дата төвлөрүүлж цуглуулах тусам мэдээлэл алдагдах, хэрэглэгчийн хувийн мэдээллийн хууль тогтоомжийг (жишээ нь GDPR) зөрчих эрсдэл нэмэгддэг.

Шийдвэр гаргах шалгуурууд

Системийн архитектур болон өгөгдлийн урсгалыг сонгохдоо дараах шалгууруудыг ашиглан харьцуулалт хийх нь зүйтэй. Үнэтэй шийдэл бүр зөв сонголт байдаггүй.

Багц болон Бодит цагийн харьцуулалт:

1. Batch (Багц боловсруулалт):

• Хэрэглээ: Санхүүгийн тайлан, сарын идэвхтэй хэрэглэгчийн тоо гаргах, машин сургалтын модел сургах.
• Давуу тал: Зардал бага, хэрэгжүүлэх болон алдаа засахад харьцангуй хялбар.
• Сул тал: Мэдээлэл хэдэн цаг эсвэл өдрөөр хоцролттой байна.

2. Streaming (Бодит цагийн урсгал):

• Хэрэглээ: Залилангийн эсрэг систем (Fraud detection), системийн уналтыг мэдээлэх, динамик үнэ тогтоолт.
• Давуу тал: Асуудалд тэр даруй хариу арга хэмжээ авах боломжтой.
• Сул тал: Дэд бүтцийн зардал маш өндөр, мэдээллийн давхардал үүсэх эрсдэлтэй, удирдахад нарийн ур чадвар шаардана.

Түгээмэл алдаанууд ба тэдгээрээс сэргийлэх нь

Өгөгдлийн төслүүд амжилтгүй болох гол шалтгаан нь технологийн дутагдал бус, харин үйл явц болон зохион байгуулалтын алдаанууд байдаг. Туршлагатай инженерийн багууд доорх алдаануудаас зайлсхийж ажилладаг:

• Хоосон үзүүлэлтэд хөтлөгдөх: Нийт бүртгүүлсэн хэрэглэгчийн тоо, нийт татсан хэмжээ зэрэг нь гаднаас харахад өсөлттэй мэт харагдах боловч бизнесийн бодит эрүүл мэндийг илэрхийлдэггүй. Үүний оронд Идэвхтэй хэрэглэгчдийн хадгалалт (Retention rate) эсвэл хэрэглэгчийн насан туршийн үнэ цэнэ (LTV) зэрэг `Actionable` буюу үйлдэл хийхэд хүргэх датаг чухалчлах шаардлагатай.
• Бүхнийг цуглуулах: "Хэзээ нэгэн цагт хэрэг болж магадгүй" гэсэн шалтгаанаар утга учиргүй их лог дата цуглуулж, өгөгдлийн сангийн зардлаа хөөргөх. Ямар асуултад хариулах гэж байгаагаа эхэлж тодорхойлоогүй дата нь ихэнхдээ хэзээ ч ашиглагддаггүй.
• Өгөгдлийн гэрээ байхгүй байх: Програм хангамж хөгжүүлэгчид мэдээллийн сангийн хүснэгтээс нэг багана устгахад бизнесийн шинжээчдийн тайлан бүхэлдээ эвдрэх тохиолдол түгээмэл байдаг. Үүнээс сэргийлж аппликейшн хөгжүүлэгчид болон өгөгдлийн инженерүүдийн дунд мэдээллийн бүтэц, чанарын талаарх өгөгдлийн гэрээ-г техникийн түвшинд хийх ёстой.

Үндсэн дүгнэлтүүд

Технологийн манлайлагчид болон инженерүүд байгууллагадаа өгөгдлийн соёлыг зөв төлөвшүүлэхийн тулд доорх зарчмуудыг анхаарах хэрэгтэй:

• Технологийн өмнө бизнесийн зорилгыг тавих: Ямар дата цуглуулах вэ гэдгээсээ өмнө ямар шийдвэрийг сайжруулах вэ гэдгээ тодорхойл. Хэрэв дата нь ямар нэгэн үйлдэл хийхэд хүргэж чадахгүй байвал тэр нь зүгээр л зардал юм.
• Үнэн зөв байдал нь хурдаас чухал: Дата буруу байснаас дата байхгүй байх нь хамаагүй дээр. Өгөгдлийн чанарыг шалгах, цэвэрлэх процессыг CI/CD дамжлагатай адил түвшинд автоматжуул.
• Хэрэгцээндээ тааруулж хөгжүүлэх: Бүх асуудлыг бодит цагийн, нарийн төвөгтэй урсгалаар (real-time streaming) шийдэх шаардлагагүй. Энгийн SQL болон өдөр тутмын багц шинэчлэл (batch update) нь бизнесийн ихэнх шаардлагыг найдвартай бөгөөд хямдаар хангаж чаддаг.
• Инженерийн хурдыг хэмжих ба удирдах: DORA зэрэг объектив хэмжүүрүүдийг ашиглаж, багийн бүтээмжийг сааруулж буй системийн гацаануудыг олж илрүүлэн тасралтгүй сайжруулалт хийх.