Skia tu kwa watu
Ku-upgrade sytem kutoka version moja kwenda nyingine sio shuhuli nyepesi, ni bora kufanya development upya
Haya mengine nimepitia katika kazi zangu za awali.
Upgrades zinaweza kuwa rahisi au ngumu kama umezingatia vitu vya msingi.
Kwa mfano upande wa off the shelf software, although most of the points are applicable for bespoke/ customized software too..
1. Muda wote kuwa na backup ya data kabla ya upgrade. Ikitokea umeharibu kazi kabisa unaweza ku install afresh na ku load data upya. Ukiharibu upgrade na data (e.g database corruption because of upgrade) wakati huna database backup, umetengeneza tatizo kubwa sana.
2. Muda wote kuwa na a tested and verified Disaster Recovery environment. Hii ni kama backup/ secondary system ambayo itaweza kukusaidia ikiwa ile primary system yako iko corrupted na upgrades.
3. Muda wote soma Release Notes za hiyo upgrades zinasemaje na uzifuatilie. Kuna siku nilikuwa nafanya upgrades system moja ya Oracle Linux bila kuzingatia sana kusoma Release Notes, kwa sababu upgrades za awali zilikuwa straightforward. Sasa kumbe, hiyo latest upgrade ilikuwa na kisehemu kidogo tu kinasema kuwa kwa servers zenye zaidi ya core 19, kuna separate patch Inabidi uanze nayo kabla ya main upgrade. Basi mimi sikuiona hiyo sehemu. Na servers zangu zilikuwa na 21 cores. Kilichotokea upgrade ilinisumbua (ili hang) na kwa karibu nusu siku nikawa nikiongea na software vendor kwenye simu, baadaye tukagundua tatizo. Kilichoniokoa ni kwamba nilikuwa nishazingatia point ya 2 hapo juu na systems zangu zilikuwa online kwa kutumia secondary servers kwa failover kwenye disaster recovery system. Kuanzia siku hiyo siwezi kufanya upgrades bila kusoma Releases Notes kikamilifu.
4. Mara zote uwe na non production/UTA/ testing environment unapoweza kufanya majaribio ya upgrade kabla ya production upgrade. Moja ya changamoto kubwa ya testing environment ni kwamba, ni vigumu kutengeneza testing environment ambayo iko sawa na production environment. Kwa systems comolex sana, unaweza kuwa na UTA (User Testing Agreement) environment ambapo users wataweza ku verify systems zao zingine zinaweza kufanya kazi na upgraded version bila matatizo.
5. Ukimaliza upgrade, hakikisha unafanya validation na kuhakiki upgrade haijaleta matatizo yoyote. Ni muhimu kuwa na watu tofauti wa kuhakiki upgrades ili kuwa na maker and checker separation.
Kuna siku miaka mingi imepita nilikuwa nafanya SQL server upgrade, ilikuwa straightforward. Nikasahau kuangalia kama upande wa logging ulikuwa unafanya kazi sawa after the upgrade. It turned out upgrade iliharibu logging. Kila kitu kilikuwa kinafanya kazi sawa, ila logging ikawa haifanyi kazi. Ilibidi nifanye patch nyingine ku address logging baada ya kuambiwa na mwenzangu kuwa logging ina matatizo.
6. Katika mchakato wote wa upgrades, hakikisha unafuatilia Change Management process, umepata ruhusa zote zinazotakiwa, umeelezea management risks involved, umetoa risk mitigation plans na rollback plans. Unafanya kazi ndani ya change window, una communication plan ya kuwaandaa watu kabla ya change, kuwaarifu watu change inapoanza, na kuwaarifu watu baada ya change. Systems upgrades huwa zinaleta matatizo, na mara nyingi watu wanaelewa hili. Lakini, kibaya zaidi ya system upgrade kuleta matatizo, ni matatizo hayo kutokea kwenye upgrade ambayo haijaruhusiwa, imefanyika kinyemela, imefanyika nje ya utaratibu au muda uliopangwa.
Hizi ni point chache za msingi kabisa za kuzingatia nilizojifunza kutoka kazi zangu za awali, points ambazo ukizizingatia, utakuwa na nafasi kubwa ya kufanya upgrades zako ziende vizuri bila matatizo au matatizo yakitokea uweze kuyatatua vizuri.
