Монолитоос микро үйлчилгээ хүртэл: M.Video-Eldorado болон MegaFon-ын туршлага

Монолитоос микро үйлчилгээ хүртэл: M.Video-Eldorado болон MegaFon-ын туршлага

25-р сарын XNUMX-нд бид Mail.ru групп дээр үүл ба эргэн тойрон дахь бага хурал зохион байгууллаа. mailto: CLOUD. Цөөн хэдэн онцлох зүйл:

  • Үндсэн Оросын үйлчилгээ үзүүлэгчид — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center болон Yandex.Cloud нар манай үүлэн зах зээлийн онцлог, тэдгээрийн үйлчилгээний талаар ярьсан;
  • Bitrix24-ийн хамтран ажиллагсад хэрхэн яаж байгаагаа хэлэв олон үүлэнд ирсэн;
  • Лерой Мерлин, Открити, Бургер Кинг, Шнайдер Электрик нар сонирхолтой үзүүлэв үүлэн хэрэглэгчдийн харах - Тэдний бизнес мэдээллийн технологийн салбарт ямар даалгавар тавьдаг, ямар технологи, тэр дундаа үүлэн технологи нь хамгийн ирээдүйтэй гэж үздэг.

Та mailto:CLOUD чуулганаас бүх видеог үзэх боломжтой холбоос, мөн энд та бичил үйлчилгээний талаарх хэлэлцүүлэг хэрхэн өрнөсөнийг уншиж болно. MegaFon бизнесийн системийн судалгаа, хөгжлийн төвийн тэргүүн Александр Деулин, M.Video-Eldorado группын мэдээллийн технологийн захирал Сергей Сергеев нар цул чулуунаас ангижрах амжилттай тохиолдлуудынхаа талаар хуваалцлаа. Мөн бид мэдээллийн технологийн стратеги, үйл явц, тэр байтугай хүний ​​нөөцийн холбоотой асуудлуудыг хэлэлцсэн.

Хэлэлцүүлэгт оролцогчид

  • Сергей Сергеев, Групп CIO "М.Видео-Эльдорадо";
  • Александр Деулин, бизнесийн системийн судалгаа, хөгжлийн төвийн дарга Мегафон;
  • Зохицуулагч - Дмитрий Лазаренко, PaaS чиглэлийн дарга Mail.ru үүлэн шийдэл.

Александр Деулин үг хэлсний дараа "MegaFon микро үйлчилгээний платформоор дамжуулан бизнесээ хэрхэн өргөжүүлж байна" Түүнийг M.Video-Eldorado-ийн Сергей Сергеев, Mail.ru Cloud Solutions-ийн хэлэлцүүлгийн модератор Дмитрий Лазаренко нар оролцуулж байна.

Доор бид танд зориулж хэлэлцүүлгийн хуулбарыг бэлтгэсэн боловч та видеог үзэх боломжтой.

Микро үйлчилгээнд шилжих нь зах зээлийн хэрэгцээнд нийцсэн хариу үйлдэл юм

Дмитрий:

Та бичил үйлчилгээ рүү амжилттай шилжиж байсан туршлагатай юу? Ерөнхийдөө: бичил үйлчилгээ ашиглах эсвэл цул үйлчилгээнээс микро үйлчилгээ рүү шилжих нь бизнесийн хамгийн их ашиг тусыг хаанаас харж байна вэ?

Сергей:

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

Хэзээ нэгэн цагт бид системийнхээ ажиллагааг хурдасгах, үйл ажиллагааны гаралтыг хурдасгах хэрэгтэйг ойлгосон. Тэр үед микро үйлчилгээ, микро үйлчилгээний арга гэх мэт ойлголтууд зах зээл дээр аль хэдийн байсан бөгөөд бид үүнийг туршиж үзэхээр шийдсэн. Энэ нь 2016 оноос эхэлсэн. Дараа нь тавцангаа тавиад эхний 10 үйлчилгээг тусдаа баг хийж хэрэгжүүлсэн.

Анхны үйлчилгээнүүдийн нэг нь хамгийн их ачаалалтай байсан нь үнэ тооцох үйлчилгээ юм. Та M.Video-Eldorado групп компанийн вэб сайт, жижиглэн худалдааны дэлгүүр гэх мэт аль ч суваг руу очих бүртээ тэндээс бараагаа сонгон, вэбсайт болон "Сагс" дээрх үнийг хараарай. нэг үйлчилгээгээр тооцсон. Энэ яагаад зайлшгүй шаардлагатай вэ: үүнээс өмнө систем бүр урамшуулалтай ажиллах өөрийн гэсэн зарчимтай байсан - хөнгөлөлт гэх мэт. Манай арын алба үнийг зохицуулдаг бөгөөд хөнгөлөлтийн функцийг өөр системд хэрэгжүүлдэг. Үүнийг төвлөрүүлж, үүнийг хэрэгжүүлэх боломжийг бидэнд олгох бизнесийн үйл явц хэлбэрээр өвөрмөц, салгах боломжтой үйлчилгээг бий болгох шаардлагатай байв. Бид бараг ингэж эхэлсэн.

Эхний үр дүнгийн үнэ цэнэ маш их байсан. Нэгдүгээрт, бид тусдаа, нэгтгэсэн байдлаар ажиллах боломжийг олгодог салгах боломжтой байгууллагуудыг бий болгож чадсан. Хоёрдугаарт, бид илүү олон системтэй нэгтгэх үүднээс өмчлөлийн зардлыг бууруулсан.

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

Микро үйлчилгээ рүү шилжих амжилтыг хэрхэн хэмжих вэ

Дмитрий:

Микро үйлчилгээ рүү шилжих амжилтыг хэрхэн тодорхойлдог вэ? Компани бүрийн "өмнө" нь юу байсан бэ? Шилжилтийн амжилтыг тодорхойлохын тулд та ямар хэмжүүр ашигласан бэ, хэн үүнийг тодорхойлсон бэ?

Сергей:

Юуны өмнө, энэ нь мэдээллийн технологийн хүрээнд шинэ боломжуудыг "нээдэг" идэвхжүүлэгч болж төрсөн. Бид зах зээлийн сорилтод хариу үйлдэл үзүүлж, харьцангуй ижил мөнгөөр ​​бүх зүйлийг хурдан хийх шаардлагатай болсон. Одоо амжилт нь өөр өөр системүүдийн дахин ашигладаг үйлчилгээний тоо, үйл явцыг хооронд нь нэгтгэх зэргээр илэрхийлэгддэг. Одоо байгаа, гэхдээ тэр үед энэ нь платформ бий болгож, бид үүнийг хийж чадна гэсэн таамаглалыг батлах боломж байсан, энэ нь үр нөлөөг өгч, бизнесийн тохиолдлыг тооцоолох болно.

Александр:

Амжилт бол дотоод мэдрэмж юм. Бизнес үргэлж илүү ихийг хүсдэг бөгөөд бидний хоцрогдлын гүн нь амжилтын баталгаа юм. Надад тийм юм шиг санагдаж байна.

Сергей:

Тиймээ, би зөвшөөрч. Гурван жилийн хугацаанд бид хоёр зуу гаруй үйлчилгээ, хоцрогдолтой болсон. Багийн доторх нөөцийн хэрэгцээ улам бүр нэмэгдэж байна - жил бүр 30%. Энэ нь хүмүүс илүү хурдан, өөр, өөр технологи байдаг, энэ бүхэн хөгжиж байна гэж мэдэрсэн учраас ийм зүйл болж байна.

Бичил үйлчилгээнүүд гарч ирэх боловч цөм нь үлдэх болно

Дмитрий:

Хөгжилдөө хөрөнгө оруулдаг хэзээ ч дуусашгүй үйл явц шиг. Бизнесийн бичил үйлчилгээнд шилжих шилжилт аль хэдийн дууссан уу, үгүй ​​юу?

Сергей:

Хариулахад маш амархан. Та юу гэж бодож байна: утас солих нь эцэс төгсгөлгүй үйл явц уу? Бид жил бүр утас худалдаж авдаг. Энд байна: хурд, зах зээлд дасан зохицох шаардлагатай бол зарим өөрчлөлт хийх шаардлагатай болно. Энэ нь бид стандарт зүйлээс татгалзана гэсэн үг биш юм.

Гэхдээ бид бүгдийг нэг дор бүрхэж, дахин хийж чадахгүй. Бидэнд өмнө нь байсан хуучин, стандарт интеграцийн үйлчилгээ байдаг: аж ахуйн нэгжийн автобус гэх мэт. Гэхдээ хоцрогдолтой, бас хэрэгцээ байгаа. Хөдөлгөөнт програмуудын тоо, тэдгээрийн үйл ажиллагаа нэмэгдэж байна. Үүний зэрэгцээ 30% илүү мөнгө өгнө гэж хэн ч хэлэхгүй. Энэ нь нэг талаас хэрэгцээ, нөгөө талаас үр ашгийг эрэлхийлэх явдал үргэлж байдаг.

Дмитрий:

Амьдрал сайхан байна. (Инээв)

Александр:

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

Гэхдээ операторын ландшафт дээр бидний худалдаж авдаг платформууд үргэлж байх тул бид үндсэн хэсгийг хадгалахаар төлөвлөж байна. Дахин хэлэхэд бидэнд эрүүл тэнцвэр хэрэгтэй: бид цөмийг таслах гэж яарах ёсгүй. Бид системүүдийг зэрэгцүүлэн байрлуулж, одоо бид олон үндсэн хэсгүүдийн орой дээр байгаа нь харагдаж байна. Цаашилбал, функцийг хөгжүүлснээр бид харилцаа холбооны үйлчилгээтэй ажилладаг бүх сувгуудад шаардлагатай дүрслэлийг бий болгодог.

Бизнесүүдэд бичил үйлчилгээг хэрхэн борлуулах вэ

Дмитрий:

Би бас сонирхож байна - шилжиж амжаагүй боловч төлөвлөж байгаа хүмүүсийн хувьд: энэ санааг бизнест зарах нь хэр хялбар байсан бэ, энэ нь адал явдал, хөрөнгө оруулалтын төсөл байсан уу? Эсвэл энэ нь ухамсартай стратеги байсан уу: одоо бид бичил үйлчилгээ рүү явж байна, тэгээд л биднийг юу ч зогсоохгүй. Таны хувьд ямар байсан бэ?

Сергей:

Бид арга барилыг биш, харин бизнесийн ашиг тусыг зарж байсан. Бизнест асуудал гарсан, бид үүнийг шийдэхийг хичээсэн. Тухайн үед янз бүрийн сувгууд үнийг тооцоолохдоо өөр өөр зарчмуудыг ашигладаг байсан нь илэрхийлэгддэг - урамшуулал, урамшуулал гэх мэт. Үүнийг засварлахад хэцүү байсан, алдаа гарсан, бид үйлчлүүлэгчдийн гомдлыг сонссон. Өөрөөр хэлбэл, бид асуудлын шийдлийг зарж байсан ч платформ бүтээхэд мөнгө хэрэгтэй болсон. Мөн тэд хөрөнгө оруулалтын эхний шатны жишээн дээр бизнесийн жишээг үзүүлэв: бид үүнийг цаашид хэрхэн нөхөх вэ, энэ нь бидэнд юу хийх боломжийг олгоно.

Дмитрий:

Та ямар нэгэн байдлаар эхний шатны цагийг тэмдэглэв үү?

Сергей:

Тийм ээ, мэдээж. Бид цөмийг платформ болгон бүтээж, туршилтыг туршихын тулд 6 сар зарцуулсан. Энэ хугацаанд бид нисгэгчийг гулгах тавцан бий болгохыг хичээсэн. Дараа нь таамаглал батлагдсан бөгөөд энэ нь ажиллаж байгаа тул бид үргэлжлүүлж болно гэсэн үг юм. Тэд багаа хуулбарлаж, хүчирхэгжүүлж эхэлсэн - тэд үүнийг хийдэг тусдаа хэлтэст шилжүүлэв.

Дараа нь бизнесийн хэрэгцээ, боломж, нөөц бололцоо, одоо ажиллаж байгаа бүх зүйл дээр суурилсан системтэй ажил орно.

Дмитрий:

БОЛЖ БАЙНА УУ. Александр, чи юу хэлэх вэ?

Александр:

Манай микро үйлчилгээнүүд нь нөөцийг хэмнэж, серверийн багтаамжийн үлдэгдэл, багийн доторх хүчийг дахин хуваарилсны улмаас "далайн хөөс" -өөс үүссэн. Анх бид энэ төслийг бизнест зараагүй. Энэ бол бид хоёрын аль аль нь судалж, үүний дагуу боловсруулсан төсөл байсан. Бид 2018 оны эхээр эхэлсэн бөгөөд зүгээр л энэ чиглэлийг урам зоригтойгоор хөгжүүлсэн. Борлуулалт дөнгөж эхэлж байгаа бөгөөд бид үйл ажиллагаагаа явуулж байна.

Дмитрий:

Бизнес танд Google гэх мэт зүйлсийг долоо хоногийн нэг чөлөөт өдөр хийх боломжийг олгодог уу? Танд ийм чиглэл бий юу?

Александр:

Судалгааны хажуугаар бид бизнесийн асуудлуудыг шийдэж байсан тул бидний бүх бичил үйлчилгээ нь бизнесийн асуудлыг шийдвэрлэх шийдэл юм. Зөвхөн эхэндээ бид захиалагчийн баазын багахан хэсгийг хамарсан бичил үйлчилгээг бүтээж байсан бөгөөд одоо бид бараг бүх тэргүүлэх бүтээгдэхүүнд байдаг.

Материаллаг нөлөөлөл нь аль хэдийн тодорхой болсон - хэрэв бид хуучин замаар явсан бол бүтээгдэхүүнээ гаргах хурд, алдагдсан орлогыг аль хэдийн тооцож болно. Үүний үндсэн дээр бид хэргийг барьж байна.

Бичил үйлчилгээ: шуугиан эсвэл хэрэгцээ юу?

Дмитрий:

Тоо бол тоо. Мөн орлого эсвэл хадгалсан мөнгө нь маш чухал юм. Нөгөө талаас нь харвал яах вэ? Бичил үйлчилгээ нь трэнд, шуугиан тарьж, олон компани үүнийг урвуулан ашиглаж байгаа юм шиг байна? Та бичил үйлчилгээ рүү орчуулдаггүй, хийдэг зүйлээ хэр тодорхой ялгадаг вэ? Хэрэв одоо өвлөгдөж байгаа бол 5 жилийн дараа та өв залгамжлалтай хэвээр байх уу? M.Video-Eldorado болон MegaFon-д ажилладаг мэдээллийн системүүд 5 жилийн дараа хэдэн нас хүрэх вэ? Арван жил, арван таван жилийн настай мэдээллийн систем байх уу, шинэ үе байх уу? Та үүнийг хэрхэн харж байна вэ?

Сергей:

Миний бодлоор их хол сэтгэнэ гэдэг хэцүү юм шиг санагддаг. Хэрэв бид эргэж харвал технологийн зах зээл ийм байдлаар хөгжинө, тэр дундаа машин сурах, хэрэглэгчийг нүүр царайгаар нь таних зэрэг болно гэж хэн төсөөлсөн бэ? Гэхдээ хэрэв та ирэх жилүүдийг харвал үндсэн системүүд, компаниудын ERP ангиллын системүүд нь нэлээд удаан хугацаанд ажиллаж байгаа юм шиг санагдаж байна.

Манай компаниуд 25 жилийн түүхтэй бөгөөд сонгодог ERP системд маш гүн гүнзгий нэвтэрсэн. Бид тэндээс зарим хэсгийг нь авч, микро үйлчилгээнд нэгтгэхийг оролдож байгаа нь тодорхой боловч гол цөм нь үлдэх болно. Одоо бид тэнд байгаа бүх үндсэн системийг сольж, шинэ системийн нөгөө, тод тал руу хурдан шилжинэ гэж төсөөлөхөд хэцүү байна.

Үйлчлүүлэгч, хэрэглэгчдэд илүү ойр байдаг бүх зүйл бол бизнесийн хамгийн том ашиг тус, үнэ цэнэ, дасан зохицох чадвар, хурд, өөрчлөлт, "оролдох, цуцлах, дахин ашиглах, өөр зүйл хийх" зэрэгт анхаарлаа төвлөрүүлдэг гэдгийг би дэмждэг. хэрэгтэй "-тэнд л ландшафт өөрчлөгдөх болно. Мөн хайрцагласан бүтээгдэхүүн тэнд тийм ч сайн тохирохгүй. Наад зах нь бид үүнийг харахгүй байна. Тэнд хамгийн хялбар, хамгийн энгийн шийдлүүд шаардлагатай.

Бид энэ хөгжлийг харж байна:

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

Гэхдээ үүнтэй зэрэгцээд хуучин зарчмыг нь зөв ашиглаж чадвал үргэлжлүүлэн ашиглахыг би дэмжиж байгаа.

Та сонгодог аж ахуйн нэгжийн системтэй гэж бодъё. Энэ нь нэг борлуулагчийн ландшафт дээр байрладаг бөгөөд бие биетэйгээ ажилладаг хоёр модулиас бүрддэг. Стандарт интеграцийн интерфейс бас байдаг. Яагаад үүнийг дахин хийж, тэнд бичил үйлчилгээ авчрах вэ?

Гэхдээ арын албанд 5 модуль байгаа бөгөөд үүнээс мэдээлэл цуглуулж, бизнесийн үйл явц болгон 8-10 фронтын систем ашигладаг бол ашиг нь шууд мэдрэгддэг. Та таван арын албаны системээс авч, бизнесийн үйл явцад төвлөрсөн тусгаарлагдсан үйлчилгээг бий болгодог. Үйлчилгээг технологийн хувьд дэвшилтэт болгох - ингэснээр мэдээллийг кэшлэх, алдаа гаргахад тэсвэртэй байхаас гадна баримт бичиг эсвэл аж ахуйн нэгжтэй ажиллах боломжтой болно. Мөн та үүнийг нэг зарчмын дагуу бүх тэргүүлэх бүтээгдэхүүнтэй нэгтгэдэг. Тэд урд талын бүтээгдэхүүнийг цуцалсан - тэд зүгээр л интеграцийг унтраасан. Маргааш та гар утасны програм бичих эсвэл жижиг вэбсайт хийж, зөвхөн нэг хэсгийг нь ажиллуулах хэрэгтэй - бүх зүйл энгийн: та үүнийг бүтээгч шиг угсарсан. Наад зах нь манай улсад энэ чиглэлд илүү их хөгжлийг харж байна.

Александр:

Сергей бидний арга барилыг бүрэн тодорхойлсон, баярлалаа. Бид хаашаа явахгүй гэдгээ л хэлье - үндсэн хэсэг, онлайн тооцооны сэдэв рүү. Өөрөөр хэлбэл, үнэлгээ, цэнэглэлт нь үнэн хэрэгтээ мөнгийг найдвартай хасдаг "том" бутлагч хэвээр байх болно. Мөн энэ системийг манай зохицуулах байгууллагууд үргэлжлүүлэн баталгаажуулах болно. Үйлчлүүлэгч рүү чиглэсэн бусад бүх зүйл бол мэдээж микро үйлчилгээ юм.

Дмитрий:

Энд гэрчилгээ олгох нь нэг түүх юм. Илүү их дэмжлэг үзүүлэх байх. Хэрэв та дэмжлэг үзүүлэхэд бага мөнгө зарцуулдаг эсвэл системд дэмжлэг, өөрчлөлт хийх шаардлагагүй бол түүнд хүрэхгүй байх нь дээр. Боломжит буулт.

Найдвартай бичил үйлчилгээг хэрхэн хөгжүүлэх вэ

Дмитрий:

Сайн байна. Гэхдээ би сонирхсон хэвээр байна. Одоо та амжилтын түүхийг ярьж байна: бүх зүйл сайхан байсан, бид бичил үйлчилгээнд шилжиж, бизнест санаагаа хамгаалж, бүх зүйл амжилттай болсон. Гэхдээ би өөр түүх сонссон.

Хэдэн жилийн өмнө банкуудад зориулсан шинэ бичил үйлчилгээний платформыг хөгжүүлэхэд хоёр жилийн хөрөнгө оруулалт хийсэн Швейцарийн компани эцэст нь төслийг хаажээ. Бүрэн сүйрсэн. Олон сая швейцарь франк зарцуулсан бөгөөд эцэст нь баг тараагдсан - энэ нь бүтсэнгүй.

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

Александр:

Амжилтгүй жишээнд бизнес эрхлэгчид тэргүүлэх чиглэлээ өөрчилж, төслүүдээ цуцалжээ. Бэлэн байдлын сайн үе шатанд (үнэндээ MVP бэлэн болсон) бизнес нь: "Бидэнд шинэ тэргүүлэх чиглэлүүд байна, бид өөр төсөл рүү шилжиж байна, бид үүнийг хааж байна."

Бидэнд бичил үйлчилгээтэй холбоотой дэлхийн хэмжээнд ямар ч алдаа гараагүй. Бид тайван унтдаг, бид бүхэл бүтэн BSS [бизнесийг дэмжих систем] үйлчилгээ үзүүлдэг 24/7 ээлжтэй.

Бас нэг зүйл бол бид хайрцагласан бүтээгдэхүүнд хамаарах дүрмийн дагуу бичил үйлчилгээг түрээслүүлдэг. Амжилтанд хүрэх түлхүүр бол та юуны түрүүнд бичил үйлчилгээг үйлдвэрлэлд бүрэн бэлтгэх багийг бүрдүүлэх хэрэгтэй. Хөгжил нь өөрөө болзолтойгоор 40% байна. Үлдсэн хэсэг нь аналитик, DevSecOps арга зүй, зөв ​​интеграцчлал, зөв ​​архитектур юм. Аюулгүй хэрэглээг бий болгох зарчимд бид онцгой анхаарал хандуулдаг. Мэдээллийн аюулгүй байдлын төлөөлөгчид төсөл бүрт архитектур төлөвлөлтийн үе шат болон хэрэгжилтийн явцад оролцдог. Тэд мөн эмзэг байдлын кодыг шинжлэх системийг удирддаг.

Бид харьяалалгүй үйлчилгээгээ ашигладаг гэж бодъё - бидэнд Кубернетес дээр байгаа. Энэ нь үйлчилгээг автоматаар нэмэгдүүлэх, автоматаар нэмэгдүүлэх зэргээс шалтгаалан хүн бүр тайван унтах боломжийг олгодог бөгөөд жижүүрийн ээлж нь зөрчлийг авдаг.

Манай микро үйлчилгээний бүхий л хугацаанд манай шугамд хүрсэн ганц хоёр тохиолдол л гарсан. Одоо үйл ажиллагаанд ямар ч асуудал байхгүй. Бид мэдээж 200 биш, 50 орчим микро үйлчилгээтэй боловч тэдгээрийг тэргүүлэх бүтээгдэхүүнүүдэд ашигладаг. Хэрэв тэд бүтэлгүйтсэн бол бид энэ талаар хамгийн түрүүнд мэдэх болно.

Бичил үйлчилгээ ба хүний ​​нөөц

Сергей:

Дэмжлэг рүү шилжүүлэх талаар хамт ажиллагсадтайгаа санал нэг байна - ажлыг зөв зохион байгуулах хэрэгтэй. Гэхдээ мэдээжийн хэрэг байгаа асуудлуудын талаар би танд хэлэх болно.

Нэгдүгээрт, технологи нь шинэ. Энэ бол сайнаар шуугиан тарьж байгаа бөгөөд үүнийг ойлгож, бүтээж чадах мэргэжилтэн олох нь том сорилт юм. Нөөцийн төлөөх өрсөлдөөн нь галзуу юм, тиймээс мэргэжилтнүүд алтаар үнэлэгддэг.

Хоёрдугаарт, тодорхой ландшафтууд бий болж, үйлчилгээний тоо нэмэгдэж байгаа тул дахин ашиглах асуудлыг байнга шийдвэрлэх ёстой. Хөгжүүлэгчдийн хийх дуртай байдаг шиг: "Одоо энд маш олон сонирхолтой зүйл бичье ..." Үүнээс болж систем өсч, мөнгө, өмчлөлийн өртөг гэх мэт үр нөлөөгөө алддаг. Өөрөөр хэлбэл, системийн архитектурт дахин ашиглах, үйлчилгээг нэвтрүүлэх, өвийг шинэ архитектурт шилжүүлэх замын зурагт оруулах шаардлагатай байна.

Өөр нэг асуудал - энэ нь өөрөө сайн боловч дотоод өрсөлдөөн юм. "Өө, шинэ загварлаг залуус энд гарч ирэв, тэд шинэ хэлээр ярьдаг." Хүмүүс мэдээж өөр. Жава хэл дээр бичиж дассан хүмүүс, Docker, Kubernetes бичдэг, ашигладаг хүмүүс байдаг. Эдгээр нь огт өөр хүмүүс, тэд өөр өөрөөр ярьдаг, өөр өөр нэр томъёо хэрэглэдэг, заримдаа бие биенээ ойлгодоггүй. Энэ утгаараа практик, мэдлэгээ хуваалцах чадвар эсвэл чадваргүй байх нь бас асуудал юм.

За, нөөцийг нэмэгдүүлэх. “Гайхалтай, явцгаая! Одоо бид илүү хурдан, илүү ихийг хүсч байна. Юу вэ, чадахгүй байна уу? Жилд хоёр дахин ихийг хүргэх боломжгүй гэж үү? Тэгээд яагаад?" Өсөн нэмэгдэж буй ийм өвдөлт нь магадгүй олон зүйл, олон арга барилд стандарт байдаг бөгөөд та үүнийг мэдэрч чадна.

Хяналтын тухайд. Миний бодлоор үйлчилгээ эсвэл үйлдвэрлэлийн хяналтын хэрэгслүүд нь Docker болон Kubernetes-тэй өөр, стандарт бус горимд аль хэдийн суралцаж эсвэл ажиллах боломжтой болсон юм шиг санагдаж байна. Тиймээс, жишээ нь, та энэ бүгдийг ажиллуулж байгаа 500 Java машинтай болж чадахгүй, тухайлбал, нэгтгэдэг. Гэхдээ эдгээр бүтээгдэхүүн нь боловсорч гүйцээгүй хэвээр байгаа тул тэд үүнийг даван туулах ёстой. Сэдэв үнэхээр шинэ, цаашид ч хөгжинө.

Дмитрий:

Тийм ээ, маш сонирхолтой. Мөн энэ нь хүний ​​нөөцөд хамаарна. Магадгүй таны хүний ​​нөөцийн үйл явц болон хүний ​​нөөцийн брэнд энэ 3 жилийн хугацаанд бага зэрэг өөрчлөгдсөн байх. Та өөр өөр чадвартай хүмүүсийг элсүүлж эхэлсэн. Мөн давуу болон сул талууд аль аль нь байж магадгүй юм. Өмнө нь блокчэйн болон мэдээллийн шинжлэх ухаан нь шуугиан тарьж байсан бөгөөд эдгээрийн мэргэжилтнүүд сая саяар үнэлэгддэг байв. Одоо зардал буурч, зах зээл ханасан, бичил үйлчилгээнд ижил төстэй хандлага ажиглагдаж байна.

Сергей:

Тийм ээ, үнэхээр.

Александр:

HR асуулт асууж байна: "Таны ягаан ганц эвэрт арын болон урд талын хооронд хаана байна?" Хүний нөөцийн мэргэжилтнүүд микро үйлчилгээ гэж юу болохыг ойлгодоггүй. Бид тэдэнд нууцыг хэлж, арын хэсэг бүгдийг хийсэн, ганц эвэрт байхгүй гэж хэлсэн. Харин хүний ​​нөөц өөрчлөгдөж, хурдан суралцаж, мэдээллийн технологийн анхан шатны мэдлэгтэй хүмүүсийг элсүүлж байна.

Микро үйлчилгээний хувьсал

Дмитрий:

Хэрэв та зорилтот архитектурыг харвал микро үйлчилгээнүүд ийм мангас шиг харагдаж байна. Таны аялал хэдэн жил үргэлжилсэн. Бусад нь нэг жил, бусад нь гурван жил байна. Та бүх асуудал, зорилтот архитектурыг урьдчилан харж байсан уу, ямар нэг зүйл өөрчлөгдсөн үү? Жишээлбэл, микро үйлчилгээний хувьд гарц, үйлчилгээний тор дахин гарч ирж байна. Та тэдгээрийг эхэндээ ашиглаж байсан уу эсвэл архитектурыг өөрчилсөн үү? Танд ийм бэрхшээл тулгардаг уу?

Сергей:

Бид хэд хэдэн харилцааны протоколуудыг аль хэдийн дахин бичсэн. Эхлээд нэг протокол байсан бол одоо нөгөө протокол руу шилжсэн. Бид аюулгүй байдал, найдвартай байдлыг нэмэгдүүлдэг. Бид Oracle, Web Logic зэрэг аж ахуйн нэгжийн технологиудаас эхэлсэн. Одоо бид микро үйлчилгээний технологийн аж ахуйн нэгжийн бүтээгдэхүүнээс татгалзаж, нээлттэй эх буюу бүрэн нээлттэй технологи руу шилжиж байна. Бид мэдээллийн санг орхиж, энэ загварт илүү үр дүнтэй ажилладаг зүйл рүү шилждэг. Бидэнд Oracle технологи хэрэггүй болсон.

Бид кэш хэр их хэрэгтэй байсан, микро үйлчилгээтэй холбоогүй ч өгөгдөл хэрэгтэй байсан үед юу хийх вэ гэх мэтийн талаар бодохгүйгээр энгийн үйлчилгээгээр эхэлсэн. Одоо бид архитектурыг тайлбарлах боломжтой платформ боловсруулж байна. Үйлчилгээний хэлээр биш, бизнесийн хэлээр бол бид үгээр ярьж эхлэхэд бизнесийн логикийг дараагийн түвшинд ав. Одоо бид үсгээр ярьж сурсан бөгөөд дараагийн түвшинд үйлчилгээнүүд нь аль хэдийн үг болсон үед, жишээлбэл, бүхэл бүтэн бүтээгдэхүүний карт байх үед зарим төрлийн нэгтгэгдэх болно. Энэ нь микро үйлчилгээнээс угсардаг, гэхдээ энэ нь дээр суурилсан API юм.

Аюулгүй байдал маш чухал. Та хүртээмжтэй болж, олон сонирхолтой зүйлийг маш хурдан, хэдхэн секундын дотор авах боломжтой үйлчилгээтэй болмогц үүнийг хамгийн найдвартай бус аргаар авах хүсэл төрдөг. Үүнээс зайлсхийхийн тулд бид туршилт, мониторинг хийх арга барилаа өөрчлөх шаардлагатай болсон. Бид баг, хүргэлтийн удирдлагын бүтэц, CI/CD-г өөрчлөх шаардлагатай болсон.

Энэ бол хувьсал юм - утаснуудын нэгэн адил илүү хурдан: эхлээд товчлууртай утаснууд гарч ирсэн, дараа нь ухаалаг утаснууд гарч ирэв. Зах зээл өөр хэрэгцээтэй байсан тул тэд бүтээгдэхүүнийг дахин бичиж, шинэчилсэн. Нэгдүгээр анги, аравдугаар анги, ажил гээд бид ингэж л хөгжиж байна.

Жилд нэг зүйлийг технологийн үүднээс, хоцрогдол, хэрэгцээ талаасаа өөр зүйлийг давтдаг. Бид нэг зүйлийг нөгөөтэй холбодог. Тус баг 20%-ийг техникийн өр болон багийн техникийн дэмжлэгт, 80%-ийг аж ахуйн нэгжид зарцуулдаг. Бид яагаад үүнийг хийж байгаа, яагаад эдгээр технологийн сайжруулалтыг хийж байгаа, энэ нь юунд хүргэх вэ гэсэн ойлголттойгоор хөдөлдөг. Ингэж.

Дмитрий:

Сайхан байна. MegaFon-д юу байдаг вэ?

Александр:

Биднийг бичил үйлчилгээнд ороход тулгарсан гол бэрхшээл бол эмх замбараагүй байдалд орохгүй байх явдал байв. MegaFon-ийн архитектурын оффис тэр даруй бидэнтэй нэгдэж, тэр байтугай санаачлагч, жолооч болсон - одоо бид маш хүчтэй архитектуртай болсон. Түүний даалгавар бол бид ямар зорилтот загвар руу явах гэж байгаа, ямар технологийг туршиж үзэх шаардлагатайг ойлгох явдал байв. Архитектурын хувьд бид эдгээр нисгэгчдийг өөрсдөө удирдсан.

Дараагийн асуулт нь: "Тэгвэл энэ бүгдийг хэрхэн ашиглах вэ?" Бас нэг зүйл: "Бичил үйлчилгээнүүдийн хоорондын ил тод харилцан үйлчлэлийг хэрхэн хангах вэ?" Үйлчилгээний сүлжээ нь сүүлийн асуултад хариулахад тусалсан. Бид Istio-г туршиж үзсэн бөгөөд үр дүн нь таалагдсан. Одоо бид бүтээмжтэй бүс рүү шилжих шатандаа байна. Бид бүх сорилтод эерэг хандлагатай байдаг - бид стекийг байнга өөрчлөх, шинэ зүйл сурах шаардлагатай байдаг. Бид хуучин шийдлүүдийг ашиглах биш, хөгжүүлэх сонирхолтой байна.

Дмитрий:

Алтан үгс! Иймэрхүү сорилтууд нь баг, бизнесийг хөл дээрээ байлгаж, ирээдүйг бий болгодог. GDPR нь мэдээлэл хамгаалах ахлах ажилтнуудыг бий болгосон бөгөөд өнөөгийн сорилтууд нь ахлах бичил үйлчилгээ, архитектурын ажилтнуудыг бий болгодог. Мөн таалагддаг.

Бид маш их ярилцсан. Хамгийн гол нь бичил үйлчилгээ, архитектурын сайн дизайн нь олон алдаанаас зайлсхийх боломжийг олгодог. Мэдээжийн хэрэг, үйл явц нь давтагдах, хувьслын шинж чанартай боловч энэ нь ирээдүй юм.

Бүх оролцогчдод баярлалаа, Сергей, Александр хоёрт баярлалаа!

Үзэгчдээс ирсэн асуултууд

Үзэгчдийн асуулт (1):

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

Сергей:

Архитектур нь өөрчлөлтийн хөдөлгөгч хүчний хувьд маш чухал гэдэгтэй би хамтран ажиллагсадтайгаа санал нэг байна. Архитектурын хэлтэстэй болсноор бид ажлаа эхэлсэн. Архитекторууд нэгэн зэрэг функциональ хуваарилалт, ландшафт дээр хэрхэн харагдах талаархи шаардлагуудын эзэд байдаг. Тиймээс тэд эдгээр өөрчлөлтийн зохицуулагчийн үүргийг гүйцэтгэдэг. Үүний үр дүнд бид CI/CD платформыг үүсгэх үед тодорхой хүргэх үйл явцад тодорхой өөрчлөлт орсон.

Гэвч стандарт, хөгжлийн үндсэн зарчим, бизнесийн шинжилгээ, туршилт, хөгжүүлэлтийг цуцалсангүй. Бид зүгээр л хурд нэмсэн. Өмнө нь цикл маш их, туршилтын орчинд суулгахад илүү их цаг зарцуулдаг байсан. Одоо бизнес ашиг тусыг нь олж хараад: "Бид яагаад бусад газарт ийм зүйлийг хийж болохгүй гэж?"

Энэ нь сайн утгаараа вакцин хэлбэрийн тарилгатай адил юм: та үүнийг ингэж хийж болно, гэхдээ та өөр аргаар хийж болно. Мэдээж боловсон хүчин, чадамж, мэдлэг, эсэргүүцэлтэй холбоотой асуудал бий.

Үзэгчдийн асуулт (2):

Микросервис архитектурыг шүүмжлэгчид туршилт, хөгжүүлэлт хийхэд хэцүү гэж хэлдэг. Бүх зүйл төвөгтэй болж байгаа тохиолдолд энэ нь логик юм. Танай хамт олон ямар сорилттой тулгарсан, тэдгээрийг хэрхэн даван туулсан бэ? Хүн бүрт зориулсан асуулт.

Александр:

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

Тухайлбал, 5-7 бичил үйлчилгээнээс бүрдсэн бүтээгдэхүүн хийж байна. Мастер салбар руу шилжих ногоон гэрлийг асаахын тулд бид бүхэл бүтэн микро үйлчилгээний стекийг нэгтгэх тест хийх хэрэгтэй. Энэ даалгавар нь бидний хувьд шинэ зүйл биш байсан: бид үүнийг BSS-д удаан хугацаанд хийж байсан бөгөөд худалдагч бидэнд аль хэдийн нийлүүлсэн шийдлүүдийг нийлүүлсэн.

Мөн бидний асуудал зөвхөн жижиг багт л байна. Нэг болзолт бүтээгдэхүүнд чанарын хяналтын нэг инженер шаардлагатай. Тиймээс бид 5-7 микро үйлчилгээний бүтээгдэхүүнийг нийлүүлдэг бөгөөд үүнээс 2-3-ыг гуравдагч этгээд хөгжүүлж болно. Жишээлбэл, манай тооцооны системийн борлуулагч болох Mail.ru групп болон MegaFon R&D хамтран боловсруулахад манай бүтээгдэхүүн бий. Үйлдвэрлэлд хүргэхийн өмнө бид үүнийг туршилтаар хамруулах хэрэгтэй. Чанарын хяналтын инженер энэ бүтээгдэхүүн дээр сар хагасын турш ажиллаж байгаа бөгөөд багийн бусад гишүүд түүний дэмжлэггүйгээр үлджээ.

Энэ нарийн төвөгтэй байдал нь зөвхөн масштабаас үүдэлтэй. Бичил үйлчилгээ нь вакуум орчинд байж болохгүй гэдгийг бид ойлгож байна; үнэмлэхүй тусгаарлалт байхгүй. Нэг үйлчилгээг өөрчлөхдөө бид үргэлж API гэрээг хадгалахыг хичээдэг. Бүрээсний доор ямар нэг зүйл өөрчлөгдсөн бол урд талын үйлчилгээ хэвээр үлдэнэ. Хэрэв өөрчлөлтүүд үхэлд хүргэх юм бол ямар нэгэн архитектурын өөрчлөлт хийгдэж, бид огт өөр өгөгдлийн мета загвар руу шилждэг бөгөөд энэ нь огт нийцэхгүй - зөвхөн тэр үед л бид v2 үйлчилгээний API тодорхойлолт гарч ирэх тухай ярих болно. Бид эхний болон хоёр дахь хувилбарыг нэгэн зэрэг дэмждэг бөгөөд бүх хэрэглэгчид хоёр дахь хувилбар руу шилжсэний дараа эхний хувилбарыг хаадаг.

Сергей:

Би нэмэхийг хүсч байна. Би хүндрэлийн талаар бүрэн санал нийлж байна - тэд тохиолддог. Ландшафт улам төвөгтэй болж, ялангуяа туршилтын зардал нэмэгдэж байна. Үүнийг хэрхэн шийдвэрлэх вэ: автоматжуулсан туршилт руу шилжих. Тийм ээ, та авто тест, нэгжийн тест бичихэд нэмэлт хөрөнгө оруулалт хийх шаардлагатай болно. Тиймээс хөгжүүлэгчид шалгалтанд тэнцэхгүйгээр үйл ажиллагаа явуулах боломжгүй тул кодыг өөрчилж чадахгүй байв. Ингэснээр автомат тест, нэгжийн туршилтгүйгээр товчлуур ч ажиллахгүй.

Өмнөх функцийг хадгалах нь чухал бөгөөд энэ нь нэмэлт зардал юм. Хэрэв та технологийг өөр протокол руу дахин бичих юм бол бүх зүйлийг бүрэн хаах хүртэл үүнийг дахин бичнэ.

Бид заримдаа төгсгөлийн туршилтыг санаатайгаар хийдэггүй, учир нь бид хөгжлийг зогсоохыг хүсдэггүй, гэхдээ бидэнд бас нэг зүйл байдаг. Ландшафт нь маш том, нарийн төвөгтэй, олон системтэй. Заримдаа энэ нь зүгээр л бүдүүлэг байдаг - тийм ээ, та аюулгүй байдлын хязгаарыг бууруулснаар илүү их эрсдэл гарч ирдэг. Гэхдээ тэр үед та нийлүүлэлтийг суллана.

Александр:

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

Үзэгчдийн асуулт (3):

Миний ойлгож байгаагаар микро үйлчилгээнүүд нь эхлээд тусдаа багаас үүссэн бөгөөд одоо энэ загварт байдаг. Үүний давуу болон сул талууд юу вэ?

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

Үүний дагуу бидний үйл ажиллагаа системд шилждэг, өөрөөр хэлбэл бид энэ сэдвийг төвлөрлийг сааруулж байна. Та ямар арга барилтай вэ, таны зорилтот түүх юу вэ?

Александр:

Та "бичил үйлчилгээний үйлдвэр" гэсэн нэрийг амнаасаа унагасан - бид бас өргөжүүлэхийг хүсч байна. Нэгдүгээрт, бид үнэхээр нэг багтай болсон. Бид MegaFon-д байгаа бүх хөгжүүлэлтийн багуудыг нийтлэг экосистемд ажиллах боломжийг олгохыг хүсч байна. Бид одоо байгаа бүх хөгжүүлэлтийн функцийг бүрэн эзэмшихийг хүсэхгүй байна. Орон нутгийн даалгавар бол цар хүрээг нэмэгдүүлэх, дэлхийн даалгавар бол микро үйлчилгээний түвшний бүх багийг хөгжүүлэх явдал юм.

Сергей:

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

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

Үүний зэрэгцээ процесс нь ерөнхий, хяналттай хэвээр байгаа бөгөөд энэ нь технологийн ерөнхий зарчмуудын дагуу, нэгжийн туршилт гэх мэт - дээр нь баригдсан бүх зүйлээр явагддаг. Бүтээгдэхүүний хандлагын янз бүрийн хэлтэсээс цуглуулсан нөөцийн хэлбэрээр багана байж болно.

Александр:

Сергей, чи үнэндээ үйл явцын эзэн юм, тийм үү? Ажлын хоцрогдол хуваалцсан уу? Түүний хуваарилалтыг хэн хариуцах вэ?

Сергей:

Хараач: энд дахин холимог байна. Технологийн сайжруулалт дээр үндэслэн бий болсон хоцрогдол байдаг - энэ бол нэг түүх юм. Төслөөс томъёолсон хоцрогдол бий, бүтээгдэхүүнээс хоцрогдол бий. Гэхдээ үйлчилгээний бүтээгдэхүүн тус бүрийг нэвтрүүлэх, эсвэл энэ үйлчилгээг бий болгох дарааллыг бүтээгдэхүүний мэргэжилтэн боловсруулдаг. Тэр Мэдээллийн технологийн хэлтэст байдаггүй, түүнийг тусгайлан хассан. Гэхдээ манайхан яг тэр л процессын дагуу ажилладаг нь гарцаагүй.

Өөр өөр чиглэлийн хоцрогдлын эзэн - өөрчлөлтийн хоцрогдол нь өөр өөр хүмүүс байх болно. Технологийн үйлчилгээний холболт, тэдгээрийн зохион байгуулалтын зарчим - энэ бүхэн МТ-д байх болно. Би платформ болон нөөцийг эзэмшдэг. Дээд талд нь хоцрогдол, функциональ өөрчлөлт, энэ утгаараа архитектуртай холбоотой зүйл юм.

Нэг бизнес: "Бид энэ функцийг хүсч байна, бид шинэ бүтээгдэхүүн бий болгохыг хүсч байна - зээлээ дахин авахыг хүсч байна" гэж хэлье. Бид: "Тийм ээ, бид үүнийг дахин хийх болно." Архитекторууд: "Бодъё: бид зээлийн хаана бичил үйлчилгээг бичих вэ, үүнийг яаж хийх вэ?" Дараа нь бид үүнийг төсөл, бүтээгдэхүүн эсвэл технологийн стек болгон хувааж, баг болгон нэгтгэж, хэрэгжүүлдэг. Та дотооддоо бүтээгдэхүүн бүтээж, энэ бүтээгдэхүүнд бичил үйлчилгээ ашиглахаар шийдсэн үү? Бид: "Одоо бидэнд байсан хуучин системүүд эсвэл урд талын системүүд эдгээр микро үйлчилгээнүүд рүү шилжих ёстой." Архитекторууд хэлэхдээ: "Тэгэхээр: технологийн хоцрогдолд тэргүүлэх чиглэлийн бүтээгдэхүүнүүд - бичил үйлчилгээ рүү шилжих явдал юм. Яв". Бүтээгдэхүүний мэргэжилтнүүд эсвэл бизнес эрхлэгчид хэдий хэмжээний хүчин чадал хуваарилагдсан, хэзээ хийх, яагаад гэдгийг ойлгодог.

Хэлэлцүүлгийн төгсгөл, гэхдээ бүгд биш

mailto:CLOUD чуулган зохион байгуулагдлаа Mail.ru үүлэн шийдэл.

Бид мөн бусад арга хэмжээг зохион байгуулдаг - жишээлбэл. @Kubernetes уулзалт, бид үргэлж гайхалтай чанга яригч хайж байдаг газар:

  • Манай Telegram сувагт @Kubernetes болон бусад @Meetup мэдээг дагаж мөрдөөрэй t.me/k8s_mail
  • @Meetups-ийн нэг дээр ярих сонирхолтой байна уу? Хүсэлт үлдээнэ үү mcs.mail.ru/speak

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх