Phoenix Project/Галт шувуу төсөл
2B | +1% better 2day | b.005
2020 оны SMART goal дотор томоохон технологийн компанид apply хийх гэж оруулсан юм. Түүнийхээ дагуу Facebook, Amazon, Apple, Microsoft, GitLab, Google-н ажлын зарыг хэсэг харж байгаад ер нь л GitLab-д Site Reliability Engineer-ээр өргөдөл өгөхөөр шийдлээ. Үүлэн технологийг бага зэрэг сурчихсан, юмыг автоматжуулах дуртай, тэгээд GitLab-н Remote Handbook-г уншсан, бас GitLab-д ажиллаж байсан Амарбаярын TedX-г сонссон зэрэг маань нөлөөлсөн байх магадлалтай. :D
Тэгээд хэрхэн apply хийх, interview яаж явагддаг, юу юу сурах/мэдэх хэрэгтэй талаар судалж, мөн гадаадад ажилладаг хүмүүсээс зөвлөгөө авав. Тэгсэн хэд хэдэн хүнээс SRE бол нэг номыг заавал уншсан байх хэрэгтэй гэж байна.
Номын нэр нь Phoenix Project.
GoodReads дээрх 30'000 гаруй үнэлгээний дундаж нь 4.3 оноо.
IT-гийн роман.
Сонин сонсогдож байгаа биз? Роман байхдаа яахавдээ. Технологийн талаар, тэр тусмаа DevOps-н талаар роман бичиж болдог юм уу?
2013 оны 1 сард хэвлэгдсэн бөгөөд 8 жилийн дараа ч гэсэн хүмүүст хэрэг болохуйц ном байна гэхээр бас л сайн ном гэж ойлгож болно.
За тэгээд шууд номруугаа оръё. Дээр хэлсэнчлэн ном нь уран зохиолын маягийн бөгөөд гол дүр маань асуудалд орсон компанийг аврах том даалгавартай. Одоо хийж байгаа ажлаа алдагдуулахгүйгээр, Галт шувуу төслийг 6 сарын дотор амжилттай дуусгах ёстой. Харин чадахгүй бол халагдах аюултай хүндхэн нөхцөлд үйл явдал өрнөнө.
Галт шувуу (Phoenix) : Грекийн домогт гардаг, шатаж үхээд, үнснээсээ дахин төрдөг шувуу. (rebirth)
Харри Поттерийг үзсэн бол Галт шувуу дахин төрөх/шинээр эхлэхийг билэгддэг гэдгийг мэдэх байх дөө. Миний хувьд ерөнхийдөө ~380 орчим хуудас номыг 3 хувааж уншсан. 1 уншчихвал амтанд нь ороод салж чадахааргүй санагдсан шүү.
Ном дотор 1 самбар, 2 өөр салбар, 3 аргачлал, 4 ажил болон 5 асуудлын талаар дурддаг. Эдгээрийг болон нэмэлт ганц 2 зүйлийг түүвэрчлэн би энэ нийтлэлдээ багтаасан байгаа.
1 самбар
Канбан самбар гэдэг нь нийт хийх ажлаа Хүлээгдэж буй, Хийж байгаа, Дууссан гэж үндсэн 3 хэсэгт хувааж харах аргачлал. Ингэснээр хийх ажлын жагсаалтыг зураглал (visual) болгох бөгөөд ойлгох болон хянахад маш амархан болгодог. (яг л GitLab board, Trello шиг гэсэн үг)
Энд бас нэг анхаарах зүйл нь Work In Progress (WIP) хэтэрхий их бөгөөд удаашралтай байх юм бол Backlog (Todo) доторх ажил нэмэгдсээр нэмэгдсээр хэзээ ч дуусгаж барахгүй болох аюултай байдаг. Тиймээс голын баганад орсон ажлыг аль болох хурдан дуусгаж, дараачийн Done руу шилжүүлэх хэрэгтэй.
2 өөр/ижил салбар : IT vs Manufacturing
Энэ 2 салбарыг хоорондоо тэс өөр юм шиг боловч бас яг ижил гэж өгүүлдэг. Товчхондоо А, Б материалуудыг ашиглан 1, 2, 3-р ажлын хэсгүүдийг дамжин өнгөрч үр дүнд нь бүтээгдэхүүн гарах ёстой. IT ч бас яг ижил. Хэрэглэгчийн шаардлагаас эхлээд, загвар гаргалт, хөгжүүлэлт, тест гээд эцсийн хэрэглэгч рүү очдог.
Хамгийн гол санаа нь системийг бүтнээр нь харж ажиллах. Жижиг хэсэг болгон тусдаа ажилладаггүй. Эцсийн бүтээгдэхүүн гарч, хэрэглэгчийн гар дээр очсон цагт л ажил дуусна гэдгийг ойлгох.
(Requirements → Design → Development →Testing → Deployment)
3 аргачлал
DevOps-г хэрэгжүүлэхэд хэрэгтэй зарчмууд, best practice нь дараах 3-н аргачлалаас үүсэлтэй гэж хэлж болно.
- Урсгал / Flow
Ажил бол эхлэлээс төгсгөл хүртэл нэг тийш урсаж явсаар дуусах учиртай. - Байнгын санал хүсэлт / Consistent Feedback
Шат болгон дээр feedback өгч, байнгын холбоотой ажиллах нь маш чухал. - Тасралтгүй суралцах / Continual learning
Шинэ зүйлийг сурах, хэрэгжүүлэх, турших соёлыг бий болгох хэрэгтэй.
IT-н бүтээгдэхүүний хувьд нэг баг нь (Development team) хөгжүүлэлтээ хийгээд дууссан болохоор нөгөө баг нь (Operations) үлдсэнийг хариуцна гэх хандлага нь хамгийн буруу зүйл байдаг байна. Учир нь хэрэглэгчийн гар дээр очоогүй л бол ажил ДУУСААГҮЙ гэсэн үг.
4 төрлийн ажил
IT компанийн хувьд өөрсдийн хийдэг ажлыг ангилан ялгаж алийг нь түрүүлж хийх вэ гэдгийг тодорхойлох хэрэгцээ гардаг. Ном дээр гарснаар дараах 4-н төрлийн ажил байдаг байна.
- Бизнесийн төслүүд / Business projects
Хамгийн чухал бөгөөд үнэ цэнэ өгөх ажлууд. Хэрэглэгчтэй шууд холбоотой бөгөөд компанийн ирээдүйтэй хамааралтай. - Дотоод IT төсөл / Internal IT projects
Дэд бүтэц болон үйл ажиллагааны төслүүд, сайжруулалтууд. Эдгээр ажлууд нь Бизнесийн төслүүдийг гүйцэтгэхэд дэм болдог. - Үйл ажиллагааны өөрчлөлт / Operational Change
Ямар ч системийн хувьд шинэчлэл, өөрчлөлт хийгдэх шаардлага гарч байдаг. Дээрх 2 төрлийн ажилтай хамааралтай hardware болон software-н ямар нэг өөрчлөлтийг 3-дах төрлийн ажил гэж үздэг байна. - Төлөвлөөгүй ажил / Unplanned work
Өмнөх 3-с үүсэж гардаг бөгөөд цаг хугацаа нь үргэлж тулгамдсан, хурдан ШИЙДЭХГҮЙ л бол болдоггүй зүйлс байдаг. Бусад бүх ажлыг зогсоох эрсдэлтэй учир хамгийн аюултай нь.
Төлөвлөөгүй ажлыг хамгийн бага байлгах талаас сайн чармайх хэрэгтэй. Үүний тулд л ITIL, Issue tracking гэх мэт хэрэгслийг ашигладаг.
5 асуудал / dysfunctions
Багаар ажиллахад үүсдэг хэд хэдэн асуудал байдаг. Эдгээр асуудлуудыг шийдэж чадахгүй бол багаараа үр дүн гаргах нь битгий хэл хамтран ажиллахад хэцүү болдог байна.
- Итгэлцэл байхгүй (Absence of trust) : баг дотроо өөрийн эмзэг сул талыг нуух
- Сөргөлдөөнөөс зугтдаг (Fear of conflict) : асуудлыг шийдэхээс илүү, хуурамч найрсаг байдлыг эрэлхийлэх
- Итгэл үнэмшилгүй байдал (Lack of commitment) : Багийн шийдвэрийг үл тоомсорлосон, өөрийгөө бүрэн дайчлахгүй байх
- Хариуцлагаас хүлээлгэхгүй (Avoidance of accountability) : Бусдыг шүүмжлэхээс, хэрэгтэй үед хариуцлага хүлээлгэхээс халгаах
- Үр дүнг чухалчлахгүй (Inattention to results) : Багийн үр дүнгийн төлөө биш зөвхөн өөрийн амжилтыг бодох
Нэг багийн хувьд шийдвэр гаргах явцдаа санал зөрөлдөж болох ч нэгэнт “А” гэж хийхээр шийдсэн л бол БҮГД шийдвэрийг хүндэтгэн, хэрэгжүүлэх ёстой. Үгүй бол багийн үр дүнд сөргөөр нөлөөлж хүссэн үр дүндээ хүрч чаддаггүй байна.
Mentor
Гол дүрийн баатарт 1 өвгөн туслах бөгөөд нэг ёсондоо ментор-лодог. Хүн ер нь дор хаяж 1 ментортой байх хэрэгтэй юм шиг ээ. Зөв буруу зааж өгнө гэхээсээ илүү ӨӨР ӨНЦӨГ гаргаж ирэх нь хамгийн чухал мэт санагдсан.
(PS: Mentor тухай 1 нийтлэл тусдаа бичсэн шүү)
Зарим юмыг шууд хэлж өгөх биш ӨӨРӨӨР нь бодуулах/мэдрүүлэх/нээлт хийлгэх хэрэгтэй.
Жишээ :
Ментор өвгөн маань гол дүрд юм зааж өгөхдөө үйлдвэрийг жишээ авч тайлбарлаж өгдөг. Учир нь хүн өөрийн мэддэг зүйл дээр үндэслэн шинэ зүйлийг сурахдаа илүү хурдан/хялбар байдаг.
Жишээ нь : Олимп гэж огт мэддэггүй 50 настай Монгол өвөөд Токио 2020-г тайлбарлахдаа; Энэ жилийн олон улсын наадам л гэсэн үг гээд хэлэхэд ойлгочихно дөө (бараг).
Constraint / Хязгаарлалт
Бүх л системд процессыг удаашруулдаг ямар 1 хүчин зүйл бий. Түүнийг олох нь маш чухал. Учир нь тухайн 1 хэсгээс хамаарч систем бүхэлдээ хэр өндөр бүтээмжтэй ажиллах нь шийдэгддэг. Тэр хүчин зүйл нь хүн, машин, технологи, процесс юу ч байж болно.
Өөрсдийнхөө constraint/limitation/bottleneck-г илрүүлэх хэрэгтэй.
Үгүй бол өөр бусад газарт хичнээн гоё/сайн сайжруулалт хийсэн ч том зургаараа үр дүнд нөлөөлдөггүй.
CIO : Career Is Over 😂
#Joke Гэхдээ томхон компаниудын хувьд үе үе солигддог, халагдах магадлал өндөртэй ажлын нэгт тооцогддог гэсэн. Дарга биш, цэрэг биш, харин дунд түвшний менежер хамгийн тогтвортой бөгөөд стресс багатай ажил гэж байна лээ. Санал нийлж байна уу?
Дүгнэлт :
Энэ номыг IT хамааралтай хүн болгон уншчихвал зүгээр санагдсан. Ерөөсөө уйтгартай биш бөгөөд ар араасаа олон үйл явдлууд цуварсаар нэг л мэдэхэд ном дуусчихна. Бас энэ нийтлэлд оруулаагүй ч Wait Time =(% Busy/%Idle) гэж нэг ойлголт бий. Би өөрөө сайн ойлгож чадаагүй болохоор оруулсангүй. Та хэд мэддэг бол хэлээд өгөөрэй.
When IT fails, business FAILS.
Одоо үед ч тэгээд IT хамааралгүй бизнес гэж байхгүй болж дээ. Миний хувьд ч бас шинэ зүйл сурсан гоё ном байлаа. Үргэлжлүүлээд Unicorn Project-г эхлүүлэхээр шийдсэн байгаа.
Сүүлчийн бодол : Хэн нэгэн нь энэ номыг Монголоор орчуулахгүй юм байхдаа? (looking for partners 😏)
Canva дээр PPT хэлбэрээр бэлдсэнийг маань бас сонирхож болно шүү.
