Сайн уу!
Намайг Михаил гэдэг, би Sportmaster компанийн мэдээллийн технологийн дэд захирал. Би тахлын үед үүссэн сорилтуудыг хэрхэн даван туулж байсан түүхийг хуваалцахыг хүсч байна.
Шинэ бодит байдлын эхний өдрүүдэд Sportmaster-ийн ердийн офлайн арилжааны формат царцаж, манай онлайн сувгийн ачаалал, ялангуяа үйлчлүүлэгчийн хаяг руу хүргэх ачаалал 10 дахин нэмэгдсэн. Хэдхэн долоо хоногийн дотор бид асар том оффлайн бизнесийг онлайн бизнес болгон хувиргаж, үйлчлүүлэгчдийнхээ хэрэгцээнд нийцүүлэн үйлчилгээгээ тохируулсан.
Үндсэндээ бидний хажуугийн үйл ажиллагаа байсан нь бидний үндсэн ажил болсон. Онлайн захиалга бүрийн ач холбогдол эрс нэмэгдсэн. Үйлчлүүлэгчийн компанид авчирсан рубль бүрийг хэмнэх шаардлагатай байв.
Үйлчлүүлэгчийн хүсэлтэд хурдан хариу өгөхийн тулд бид компанийн төв оффис дээр нэмэлт холбоо барих төвийг нээсэн бөгөөд долоо хоногт 285 мянга орчим дуудлага хүлээн авах боломжтой болсон. Үүний зэрэгцээ бид 270 дэлгүүрийг контактгүй, аюулгүй ажиллагааны шинэ хэлбэрт шилжүүлснээр үйлчлүүлэгчид захиалга авч, ажилчид нь ажлын байраа хадгалах боломжтой болсон.
Өөрчлөлтийн явцад бид хоёр үндсэн асуудалтай тулгарсан. Нэгдүгээрт, манай онлайн нөөцийн ачаалал мэдэгдэхүйц нэмэгдсэн (Сергей бид үүнийг хэрхэн шийдсэнийг танд хэлэх болно). Хоёрдугаарт, ховор (COVID-ийн өмнөх) үйл ажиллагааны урсгал хэд дахин нэмэгдсэн бөгөөд энэ нь эргээд их хэмжээний хурдан автоматжуулалтыг шаарддаг. Энэ асуудлыг шийдэхийн тулд бид өмнө нь гол байсан газруудаас нөөцийг хурдан шилжүүлэх шаардлагатай болсон. Бид үүнийг хэрхэн шийдсэнийг Елена танд хэлэх болно.
Онлайн үйлчилгээний үйл ажиллагаа
Колесников Сергей, онлайн дэлгүүр, бичил үйлчилгээний үйл ажиллагааг хариуцдаг
Манай жижиглэнгийн дэлгүүрүүд зочдод ойртож эхэлсэн тэр мөчөөс эхлэн хэрэглэгчдийн тоо, манай аппликешнд өгсөн захиалгын тоо, аппликешнд ирүүлсэн хүсэлтийн тоо зэрэг үзүүлэлтүүдийн өсөлтийг тэмдэглэж эхэлсэн.
18-р сарын 31-аас XNUMX-р сарын XNUMX хүртэлх захиалгын тооОнлайн төлбөрийн бичил үйлчилгээнд хандсан хүсэлтийн тооСайт дээр байрлуулсан захиалгын тоо
Эхний график дээр бид өсөлт нь ойролцоогоор 14 дахин, хоёр дахь нь 4 дахин их байгааг харж байна. Бид аппликешны хариу өгөх хугацааны хэмжигдэхүүнийг хамгийн их үзүүлэлт гэж үздэг.
Энэ графикаас бид фронт болон хэрэглээний хариуг харж байгаа бөгөөд бид ийм өсөлтийг анзаараагүй гэдгээ өөрсдөө тодорхойлсон.
Энэ нь юуны түрүүнд бид 2019 оны сүүлээр бэлтгэл ажлаа эхлүүлсэнтэй холбоотой. Одоо манай үйлчилгээнүүд хадгалагдаж, физик серверүүд, виртуалчлалын системүүд, докерууд, тэдгээрийн үйлчилгээний түвшинд алдааг тэсвэрлэх чадвартай болсон. Үүний зэрэгцээ манай серверийн нөөцийн хүчин чадал нь олон ачааллыг тэсвэрлэх боломжийг олгодог.
Энэ бүх түүхэнд бидэнд тусалсан гол хэрэгсэл бол бидний хяналтын систем байв. Саяхныг хүртэл бидэнд физик төхөөрөмж, техник хангамжийн түвшнээс эхлээд бизнесийн хэмжүүрийн түвшин хүртэлх бүх давхаргад хэмжигдэхүүнийг цуглуулах боломжийг олгодог нэг систем байгаагүй нь үнэн.
Албан ёсоор компанид хяналт тавьдаг байсан боловч дүрмээр бол тарааж, тодорхой хэлтсийн хариуцлагын хүрээнд байсан. Үнэн хэрэгтээ, ямар нэгэн үйл явдал тохиолдоход бид яг юу болсон талаар нэгдсэн ойлголттой бараг хэзээ ч байгаагүй, харилцаа холбоо байхгүй байсан бөгөөд энэ нь ихэвчлэн асуудлыг шийдэхийн тулд асуудлыг олж, тусгаарлахын тулд дугуйлан гүйдэг байв.
Хэзээ нэгэн цагт бид үүнийг тэвчих хангалттай гэж бодож, шийдсэн - бидэнд бүх дүр зургийг бүрэн харахын тулд нэгдсэн систем хэрэгтэй. Манай стект багтсан гол технологи бол дохиолол, хэмжигдэхүүн хадгалах төв болох Zabbix, хэрэглээний хэмжигдэхүүнүүдийг цуглуулах, хадгалах Prometheus, бүх хяналтын системээс өгөгдлийг бүртгэх, хадгалах Stack ELK, түүнчлэн дүрслэх зориулалттай Grafana, Swagger, Docker юм. болон бусад хэрэгцээт зүйлс болон танд танил зүйлс.
Үүний зэрэгцээ бид зах зээл дээр байгаа технологиудыг ашиглаад зогсохгүй өөрсдийнхөө заримыг хөгжүүлдэг. Жишээлбэл, бид системийг бие биетэйгээ нэгтгэх үйлчилгээ, өөрөөр хэлбэл хэмжүүр цуглуулах зарим төрлийн API хийдэг. Дээрээс нь бид өөрсдийн хяналтын систем дээр ажиллаж байна - бизнесийн хэмжүүрийн түвшинд бид UI тестийг ашигладаг. Мөн багууддаа мэдэгдэх Telegram дахь робот.
Мөн бид мониторингийн системийг багуудад хүртээмжтэй болгохыг хичээж байгаа бөгөөд ингэснээр тэд өөрсдийн хэмжигдэхүүнийг бие даан хадгалж, ажиллах боломжтой, тэр дундаа өргөн хэрэглэгддэггүй зарим нарийн хэмжигдэхүүнүүдэд анхааруулга тохируулах боломжтой.
Системийн хэмжээнд бид аль болох түргэн шуурхай ажиллаж, зөрчлийг нутагшуулахыг эрмэлздэг. Нэмж дурдахад манай микро үйлчилгээ, системүүдийн тоо сүүлийн үед мэдэгдэхүйц нэмэгдэж, интеграцийн тоо ч нэмэгдсээр байна. Интеграцчлалын түвшинд ослыг оношлох үйл явцыг оновчтой болгохын тулд бид систем хоорондын шалгалтыг хийж, үр дүнг харуулах боломжийг олгодог системийг боловсруулж байгаа бөгөөд энэ нь импорт, системийн харилцан үйлчлэлтэй холбоотой гол асуудлуудыг олох боломжийг олгодог. бие биенээ.
Мэдээжийн хэрэг, бид үйлдлийн системийн хувьд өсөж хөгжих орон зай хэвээр байгаа бөгөөд бид энэ тал дээр идэвхтэй ажиллаж байна. Та манай хяналтын системийн талаар илүү ихийг уншиж болно .
Техникийн туршилтууд
Орлов Сергей, вэб болон гар утасны хөгжлийн төвийг удирддаг
Дэлгүүрийг хааж эхэлснээс хойш бид хөгжлийн үүднээс янз бүрийн сорилтуудтай тулгарсан. Юуны өмнө ачааллын огцом өсөлт. Хэрэв зохих арга хэмжээ авахгүй бол системд өндөр ачаалал өгөх үед энэ нь гунигтай тэсрэлт бүхий хулуу болж хувирах, эсвэл гүйцэтгэлийг бүрэн доройтуулж, бүр үйл ажиллагаагаа алдаж болзошгүй нь тодорхой байна.
Хоёрдахь тал нь бага зэрэг ойлгомжтой зүйл бол өндөр ачаалалтай системийг бизнесийн үйл явцын өөрчлөлтөд тохируулан маш хурдан өөрчлөх шаардлагатай болсон явдал юм. Заримдаа өдөрт хэд хэдэн удаа. Олон компаниуд маркетингийн үйл ажиллагаа ихтэй бол системд ямар нэгэн өөрчлөлт оруулах шаардлагагүй гэсэн дүрэмтэй байдаг. Ямар ч биш, ажиллаж байгаа цагтаа ажиллаасай.
Тэгээд бид үндсэндээ эцэс төгсгөлгүй Хар Баасан гараг байсан бөгөөд энэ үеэр системийг өөрчлөх шаардлагатай байв. Мөн систем дэх аливаа алдаа, асуудал, доголдол нь бизнест маш их өртөгтэй байх болно.
Урагшаа харахад бид эдгээр туршилтуудыг даван туулж, бүх системүүд ачааллыг тэсвэрлэж, амархан масштабтай, дэлхийн хэмжээнд техникийн ямар ч доголдолтой тулгараагүй гэж хэлэх болно.
Системийн өндөр хүчдэлийн ачааллыг тэсвэрлэх чадвар нь дөрвөн тулгуур дээр суурилдаг. Тэдгээрийн эхнийх нь дээр дурдсаныг уншсан мониторинг юм. Суурилуулсан хяналтын системгүй бол системийн саатлыг олох нь бараг боломжгүй юм. Сайн хяналтын систем нь гэрийн хувцастай адил бөгөөд энэ нь биед эвтэйхэн, танд тохирсон байх ёстой.
Хоёрдахь тал бол туршилт юм. Бид энэ асуудлыг маш нухацтай авч үздэг: бид сонгодог нэгжүүд, нэгтгэх тестүүд, ачааллын тестүүд болон бусад олон програмуудыг систем тус бүрээр бичдэг. Бид туршилтын стратеги бичиж байгаа бөгөөд үүний зэрэгцээ туршилтын түвшинг гар аргаар шалгах шаардлагагүй болтлоо нэмэгдүүлэхийг хичээж байна.
Гурав дахь тулгуур нь CI/CD дамжуулах хоолой юм. Аппликейшн бүтээх, турших, ашиглах үйл явцыг аль болох автоматжуулсан байх ёстой бөгөөд гар ажиллагаатай байх ёсгүй. CI/CD Pipeline-ийн сэдэв нь нэлээд гүнзгий бөгөөд би энэ тухай товчхон ярих болно. Бидэнд CI/CD дамжуулах хоолойн хяналтын хуудас байдгийг дурдах нь зүйтэй бөгөөд үүнийг бүтээгдэхүүний баг бүр ур чадварын төвүүдийн тусламжтайгаар шалгадаг.
Мөн энд шалгах хуудас байна
Ингэж байж олон зорилго биелдэг. Энэ нь API хувилбар болон функцийг солихоос сэргийлж, туршилтыг бүрэн автоматжуулсан, байршуулалт нь саадгүй байх гэх мэт түвшинд янз бүрийн туршилтуудыг хамрах боломжийг олгодог.
Дөрөв дэх тулгуур нь архитектурын зарчим, техникийн шийдэл юм. Архитектурын талаар бид удаан хугацаанд ярьж болох ч би анхаарлаа хандуулахыг хүсч буй хэд хэдэн зарчмыг онцлон тэмдэглэхийг хүсч байна.
Эхлээд та тодорхой ажлуудад зориулсан тусгай хэрэгслийг сонгох хэрэгтэй. Тийм ээ, энэ нь ойлгомжтой сонсогдож байгаа бөгөөд хадаасыг алхаар цохиж, бугуйн цагийг тусгай халиваар задлах нь ойлгомжтой. Гэвч бидний эрин үед олон хэрэгслүүд хэрэглэгчдийн хамгийн их хэсгийг хамардаг: мэдээллийн сан, кэш, фреймворк болон бусад зүйлийг хамрахын тулд түгээмэл болгохыг хичээдэг. Жишээлбэл, хэрэв та MongoDB мэдээллийн санг авбал энэ нь олон баримт бичгийн гүйлгээтэй, Oracle мэдээллийн сан json-тэй ажилладаг. Мөн бүх зүйлийг бүх зүйлд ашиглаж болох юм шиг санагддаг. Гэхдээ хэрэв бид бүтээмжийн төлөө зогсох юм бол хэрэгсэл бүрийн давуу болон сул талуудыг тодорхой ойлгож, өөрт хэрэгтэй зүйлүүдийг ангиллын ажилдаа ашиглах хэрэгтэй.
Хоёрдугаарт, системийг зохион бүтээхдээ нарийн төвөгтэй байдлын өсөлт бүрийг зөвтгөх ёстой. Бид үүнийг байнга санаж байх ёстой, бага холболтын зарчим нь хүн бүрт мэдэгддэг. Үүнийг тодорхой үйлчилгээний түвшинд, бүхэл бүтэн системийн түвшинд, архитектурын ландшафтын түвшинд хэрэгжүүлэх ёстой гэж би үзэж байна. Ачааллын замын дагуу системийн бүрэлдэхүүн хэсэг бүрийг хэвтээ байдлаар масштаблах чадвар нь бас чухал юм. Хэрэв та ийм чадвартай бол масштаблах нь хэцүү биш байх болно.
Техникийн шийдлүүдийн тухай ярихад бид бүтээгдэхүүний багуудаас шинэ зөвлөмж, санаа, шийдлүүдийг бэлтгэхийг хүссэн бөгөөд тэд дараагийн ачааллын давалгаанд бэлтгэх зорилгоор хэрэгжүүлсэн.
Кеши
Орон нутгийн болон тархсан кэшийг сонгохдоо ухамсартай хандах шаардлагатай. Заримдаа нэг систем дотор хоёуланг нь ашиглах нь утга учиртай байдаг.Жишээ нь, зарим өгөгдөл нь үндсэндээ дэлгэцийн кэш, өөрөөр хэлбэл шинэчлэлтийн эх сурвалж нь системийн ард байрладаг, систем өөрчлөгддөггүй системүүд байдаг. энэ өгөгдөл. Энэ аргын хувьд бид орон нутгийн Caffeine Cache ашигладаг.
Үйл ажиллагааны явцад систем идэвхтэй өөрчлөгддөг өгөгдөл байдаг бөгөөд энд бид Hazelcast-тай тараагдсан кэшийг аль хэдийн ашиглаж байна. Энэ арга нь бидэнд түгээсэн кэшийн ашиг тусыг үнэхээр хэрэгцээтэй газар ашиглах боломжийг олгож, үүнгүйгээр хийх боломжтой Hazelcast кластерын өгөгдлийг эргэлтэнд оруулах үйлчилгээний зардлыг багасгах боломжийг олгодог. Бид кэшийн талаар маш их бичсэн. и .
Нэмж дурдахад, Hazelcast дахь сериалчлагчийг Kryo болгон өөрчилсөн нь бидэнд сайн түлхэц өгсөн. Мөн Hazelcast дахь ReplicatedMap-аас IMap + Near Cache руу шилжсэнээр кластер дахь өгөгдлийн хөдөлгөөнийг багасгах боломжийг бидэнд олгосон.
Бяцхан зөвлөгөө: бөөн кэш хүчингүй болсон тохиолдолд хоёр дахь кэшийг дулаацуулж, дараа нь түүн рүү шилжих тактикийг заримдаа хэрэглэж болно. Энэ аргын тусламжтайгаар бид хоёр дахин санах ойн хэрэглээг авах ёстой юм шиг санагдаж байна, гэхдээ практик дээр үүнийг хэрэгжүүлсэн системүүдэд санах ойн зарцуулалт буурсан байна.
Реактив стек
Бид реактив стекийг маш олон тооны системд ашигладаг. Манай тохиолдолд энэ нь Webflux эсвэл coroutines бүхий Котлин юм. Оролтын гаралтын үйл ажиллагаа удаан хүлээгдэж байгаа үед реактив стек нь ялангуяа сайн байдаг. Жишээлбэл, үйлчилгээг удаашруулах, файлын систем эсвэл хадгалах системтэй ажиллах дуудлага.
Хамгийн чухал зарчим бол дуудлагыг хаахаас зайлсхийх явдал юм. Реактив фреймворкууд нь бүрхүүлийн доор ажилладаг цөөн тооны амьд үйлчилгээний урсгалтай байдаг. Хэрэв бид хайхрамжгүй байдлаар JDBC драйверын дуудлага гэх мэт шууд хаах дуудлага хийхийг зөвшөөрвөл систем зүгээр л зогсох болно.
Алдааг өөрийн ажиллах үеийн онцгой тохиолдол болгон хувиргахыг хичээгээрэй. Хөтөлбөрийн гүйцэтгэлийн бодит урсгал нь реактив хүрээ рүү шилжиж, кодын гүйцэтгэл нь шугаман бус болдог. Үүний үр дүнд стекийн ул мөрийг ашиглан асуудлыг оношлоход маш хэцүү байдаг. Энд байгаа шийдэл нь алдаа бүрт тодорхой, объектив ажиллах үеийн үл хамаарах зүйлсийг бий болгох явдал юм.
Elasticsearch
Elasticsearch-г ашиглахдаа ашиглагдаагүй өгөгдлийг бүү сонго. Энэ нь зарчмын хувьд маш энгийн зөвлөгөө боловч ихэнхдээ үүнийг мартдаг. Хэрэв та нэг удаад 10 мянга гаруй бичлэг сонгох шаардлагатай бол Scroll-ийг ашиглах хэрэгтэй. Аналогийг ашиглахын тулд энэ нь харилцааны мэдээллийн сан дахь курсортой төстэй юм.
Шаардлагагүй бол дараах шүүлтүүрийг бүү ашигла. Үндсэн түүвэрт их хэмжээний өгөгдөлтэй бол энэ үйлдэл нь мэдээллийн санг ихээхэн ачаалдаг.
Боломжтой тохиолдолд бөөнөөр нь үйлд.
API
API-г зохион бүтээхдээ дамжуулагдсан өгөгдлийг багасгахад тавигдах шаардлагуудыг оруулаарай. Энэ нь ялангуяа урд талын хувьд үнэн юм: яг энэ уулзвар дээр бид дата төвийнхөө сувгуудаас давж, үйлчлүүлэгчтэй холбох суваг дээр аль хэдийн ажиллаж байна. Хэрэв энэ нь өчүүхэн асуудалтай бол хэт их ачаалал нь хэрэглэгчийн сөрөг туршлагад хүргэдэг.
Эцэст нь хэлэхэд, олон тооны өгөгдлийг бүү хая, хэрэглэгчид болон ханган нийлүүлэгчдийн хооронд байгуулсан гэрээний талаар тодорхой байгаарай.
Байгууллагын өөрчлөлт
Ерошкина Елена, Мэдээллийн технологийн дэд захирал
Хорио цээрийн дэглэм тогтоож, онлайн хөгжлийн хурдыг эрс нэмэгдүүлж, олон сувгийн үйлчилгээг нэвтрүүлэх шаардлага үүссэн энэ үед бид аль хэдийн зохион байгуулалтын өөрчлөлтийн шатандаа явж байсан.
Манай бүтцийн нэг хэсэг нь бүтээгдэхүүний хандлагын зарчим, практикийн дагуу ажиллахад шилжсэн. Одоо бүтээгдэхүүн бүрийн үйл ажиллагаа, боловсруулалтыг хариуцдаг багууд байгуулагдсан. Ийм багуудын ажилчид 100% оролцдог бөгөөд өөрт илүүд үздэг зүйл, байршуулах шугам тавих, техникийн практикийг хэрэгжүүлэх, чанарын баталгаажуулалтын практик болон бусад зүйлээс хамааран Scrum эсвэл Kanban ашиглан ажлаа зохион байгуулдаг.
Азаар манай бүтээгдэхүүний багуудын дийлэнх нь онлайн болон олон сувгийн үйлчилгээний чиглэлээр ажилладаг байв. Энэ нь үр ашгийг алдалгүйгээр хамгийн богино хугацаанд (ноцтойгоор, шууд утгаараа хоёр өдрийн дотор) алсын ажлын горимд шилжих боломжийг бидэнд олгосон. Өөрчлөн тохируулсан үйл явц нь шинэ ажлын нөхцөлд хурдан дасан зохицож, шинэ функцийг хүргэх нэлээд өндөр хурдыг хадгалах боломжийг бидэнд олгосон.
Нэмж дурдахад бид онлайн бизнесийн хил дээр байгаа багийг бэхжүүлэх шаардлагатай байна. Бид дотоод нөөц бололцоогоо ашиглан үүнийг хийх боломжтой гэдэг нь тухайн үед тодорхой болсон. Мөн хоёр долоо хоногийн дотор 50 орчим хүн өмнө нь ажиллаж байсан газраа сольж, өөрт шинэ бүтээгдэхүүн гаргах ажилд оролцов.
Энэ нь менежментийн тусгай хүчин чармайлт шаарддаггүй, учир нь бид өөрсдийн үйл явцыг зохион байгуулах, бүтээгдэхүүний техникийн сайжруулалт, чанарын баталгаажуулалтын туршлагыг хэрэгжүүлэхийн зэрэгцээ багууддаа захиргааны нөөцийг оролцуулалгүйгээр үйлдвэрлэлийн үйл явцыг өөрсдөө зохион байгуулахыг заадаг.
Бид удирдлагын нөөцөө тухайн үед хэрэгтэй байсан газарт нь төвлөрүүлж чадсан - бизнестэйгээ уялдаа холбоотой: Манай үйлчлүүлэгчийн хувьд яг одоо юу чухал вэ, юуны өмнө ямар функцийг хэрэгжүүлэх ёстой вэ, дамжуулах чадвараа нэмэгдүүлэхийн тулд юу хийх хэрэгтэй вэ. захиалгыг хүргэх, боловсруулах. Энэ бүхэн болон тодорхой үлгэр дуурайлал нь энэ хугацаанд үйлдвэрлэлийн үнэ цэнийн урсгалыг үнэхээр чухал бөгөөд шаардлагатай зүйлээр цэнэглэх боломжийг олгосон.
Алсын ажил, өөрчлөлтийн өндөр хурдтай үед бизнесийн үзүүлэлтүүд хүн бүрийн оролцооноос шалтгаалдаг бол "Бидэнд бүх зүйл сайхан болж байна уу?" цувралын дотоод мэдрэмжинд найдах боломжгүй нь ойлгомжтой. Тийм ээ, сайхан санагдаж байна." Үйлдвэрлэлийн үйл явцын объектив хэмжүүрүүд шаардлагатай. Эдгээр нь бидэнд байгаа бөгөөд эдгээр нь бүтээгдэхүүний багийн хэмжүүрийг сонирхож буй хэн бүхэнд боломжтой. Юуны өмнө баг өөрөө, бизнес, туслан гүйцэтгэгч, удирдлага.
Хоёр долоо хоногт нэг удаа баг бүртэй статусыг зохион байгуулж, 10 минутын турш хэмжүүрүүдэд дүн шинжилгээ хийж, үйлдвэрлэлийн үйл явц дахь саад бэрхшээлийг тодорхойлж, эдгээр саад бэрхшээлийг арилгахын тулд юу хийж болох талаар хамтарсан шийдлийг боловсруулдаг. Тодорхойлсон асуудал нь багуудын нөлөөллийн бүсээс гадуур байгаа эсвэл үүнтэй төстэй асуудалтай тулгарсан хамт ажиллагсдынхаа туршлагаас гадуур байвал та эндээс яаралтай тусламж хүсэх боломжтой.
Гэсэн хэдий ч бид хэд хэдэн удаа хурдасгахын тулд (мөн энэ бол бидний өмнөө тавьсан зорилго юм) бид маш их зүйлийг сурч, өдөр тутмын ажилдаа хэрэгжүүлэх хэрэгтэй гэдгийг ойлгож байна. Яг одоо бид бүтээгдэхүүнийхээ хандлагыг бусад баг болон шинэ бүтээгдэхүүнүүдэд өргөжүүлэх ажлыг үргэлжлүүлж байна. Үүнийг хийхийн тулд бид шинэ формат болох арга зүйчдийн онлайн сургуулийг эзэмших шаардлагатай болсон.
Арга зүйчид, багуудад үйл явцыг бий болгох, харилцаа холбоо тогтоох, ажлын үр ашгийг дээшлүүлэхэд тусалдаг хүмүүс бол үндсэндээ өөрчлөлтийн төлөөлөгч юм. Яг одоо манай нэгдүгээр ангийн төгсөгчид багаар ажиллаж, амжилтанд хүрэхэд нь тусалж байна.
Өнөөгийн нөхцөл байдал нь бидний хувьд одоохондоо бүрэн ухамсарлаагүй байгаа боломж, хэтийн төлөвийг нээж өгч байна гэж бодож байна. Гэхдээ яг одоо олж авч байгаа туршлага, дадлага нь бид хөгжлийн зөв замыг сонгож, ирээдүйд эдгээр шинэ боломжуудыг алдахгүй бөгөөд Спортмастерт тулгараад буй сорилтод үр дүнтэй хариу өгөх боломжтой гэдгийг баталж байна.
үр дүн нь
Энэ хүнд хэцүү үед бид програм хангамжийг хөгжүүлэх үндсэн зарчмуудыг тодорхойлсон бөгөөд энэ нь үүнтэй харьцдаг компани бүрт хамааралтай байх болно гэж би бодож байна.
хүн. Үүнд бүх зүйл тулгуурладаг. Ажилтнууд ажлаасаа таашаал авч, компанийн зорилго, ажиллаж буй бүтээгдэхүүнийхээ зорилгыг ойлгох ёстой. Мэдээжийн хэрэг, тэд мэргэжлийн хувьд хөгжих боломжтой.
Технологи. Компани нь технологийн стектэйгээ ажиллахад төлөвшсөн арга барилыг авч, үнэхээр шаардлагатай газарт ур чадварыг бий болгох шаардлагатай байна. Энэ нь маш энгийн бөгөөд ойлгомжтой сонсогдож байна. Мөн ихэнхдээ үл тоомсорлодог.
Үйл явц. Бүтээгдэхүүний баг, чадамжийн төвүүдийн ажлыг зөв зохион байгуулах, бизнестэй хамтран ажиллахын тулд түүнтэй харилцах харилцааг бий болгох нь чухал юм.
Ерөнхийдөө бид ийм байдлаар амьд үлдсэн. Бидний үеийн гол сургаал духан дээр нь цуурайтсанаар дахин батлагдлаа
Хэдийгээр та өөрийн үйл ажиллагаа явуулдаг олон дэлгүүр, олон хоттой асар том оффлайн бизнес байсан ч онлайн бизнесээ хөгжүүлээрэй. Энэ бол зүгээр л нэмэлт борлуулалтын суваг эсвэл ямар нэгэн зүйл худалдаж авах боломжтой сайхан програм биш юм (мөн өрсөлдөгчид ч гэсэн үзэсгэлэнтэй байдаг). Энэ бол шуургыг даван туулахад туслах нөөц дугуй биш юм.
Энэ бол туйлын хэрэгцээ юм. Үүний тулд зөвхөн техникийн чадавхи, дэд бүтцээ төдийгүй хүмүүс, үйл явцаа бэлтгэх ёстой. Эцсийн эцэст та хэдхэн цагийн дотор нэмэлт санах ой, зай худалдаж авах, шинэ инстанцуудыг байрлуулах гэх мэтийг хурдан авах боломжтой. Гэхдээ үүнд хүмүүс, үйл явцыг урьдчилан бэлтгэх хэрэгтэй.
Эх сурвалж: www.habr.com