Ticari yazılımları yükseltme stratejisi nasıl belgelenir?


11

Yaklaşık on yıldır RDBMS veya sunucu işletim sistemimizi yükseltmedik. Görev açısından kritik bir başka yazılım paketi de yirmi yaşına yaklaşıyor ve satıcısı tarafından o zamandan beri desteklenmiyor. Bazı yönetim arasında bu iyi bir şey olduğunu düşünüyor gibi görünüyor - biz yükseltmeleri satın alarak ton tasarruf! Şimdi kritik bir yazılım parçasının yükseltilmesi gerekiyor, ancak yeni sürüm on yıllık şeyleri desteklemeyecek. Şimdi bir avuç dolusu saçımızı kaybediyoruz.

Gelecekte bundan kaçınmak için, birçoğumuz bir BT stratejik plan belgesi oluşturmayı düşünüyoruz (bu, kuruluşun katman planına uyacak, BT ile ilgili daha büyük dokümandaki öğeleri temizleyecektir ... belki BT belgesini taktik yaparplan?) ajansın genel stratejik planının bir parçası olarak benimsenmesini umuyoruz. Yukarıda belirtilen sorunu çözmek için "Yazılım Yaşam Döngüsü Yönetimi" (veya bunun gibi bir şey) bölümünü denemeye ve birleştirmeye gönüllü oldum (muhtemelen pirinç planlarla stratejik plandan ayrı bir belgede). Neredeyse tüm yazılım satıcıları, ürünleri için yaşam döngüleri ve kullanımdan kaldırma planları yayınlar ve bu bilgileri kuruluşumuzun ihtiyaçları ile birlikte dikkate alarak her bir yazılım parçası için "tatlı bir nokta" belirlemek yeterince kolaydır. Zor kısım (benim için her neyse), her bir parçanın planını daha uyumlu bir şeye bir araya getiriyor.

A, B, C ... masaüstü istemcilerinin masaüstü OS X ve RDBMS Y'ye bağlı olduğunu nasıl belgeleyebilirim, bu da sunucu OS Z'ye bağlıdır ve sonra hepsini "tatlı noktalarında" nasıl saklıyoruz? Orada kitaplar olmalı, ancak tüm googling'im beni sadece bu taktikleri ne zaman uygulayacağınızı belirleme stratejisinden ziyade tek bir yazılım parçasını yükseltme taktikleri hakkında yönlendirdi.


7
Birisi yakında bu konuda gitmek için birlikte olacak, eminim, ama kaçırılmaması gereken olduğunu düşünüyorum bir nokta, şirket yükseltmeleri para harcamak değil , iş risk altında olduğunu . Yapmamız gereken şeylerden biri, yönetimi yükseltme yapmamanın risklerinden haberdar etmektir.
Michael Hampton

3
Yükseltmeleri ertelemek için bir terim “teknolojik borç” oluşturduğunuzdır; düzenli bakım ve yükseltmeleri erteleyerek kısa vadede biraz para biriktiriyor gibi görünüyorsunuz, ancak sonunda yıllarca ihmalden sonra bakım yapmanız gerektiğinde, piper'i ödemeniz gerekecektir: genellikle zamanlama talihsiz olacaktır, satıcılar desteklenen bir acil geçme fırsatı yakaladı $CURRENT-version minus 20 yearsiçin $CURRENT-versionvs ve muhtemelen sonuca ulaşacak: Bunlar gerçek tasarruf fakat dEĞİL vardı GİDERLERİ gerekecek gelecekteki bir tarihte ödeme .
HBruijn

1
Yaşam döngüsü yönetimi, herhangi bir olgun ortamda nankör bir zorunluluktur ve organize etmek için bir PITA'dır. İyi şanslar!
HBruijn

Yanıtlar:


7

Görünüşe göre birçok sorunu aynı anda çözmeye çalışıyorsunuz (ve iyi bir fikir gibi görünmüyor).

Ne okuduğumdan:

  • eski işletim sistemi ve uygulamalar
  • uzun vadeli strateji yok
  • altyapınızı belgeleme sorunları
  • kritik altyapıyı iyileştirmek için acil ihtiyaç

"Kritik yazılım parçası" nı yükseltme

Birinin kararı nedeniyle altyapınızın güncelliğini yitirmesi kolaydır. Muhtemelen geçmişte iyi bir fikir gibi görünüyordu. Bu, Michael Hampton'un yorumlarda yazdığı şeye dayanıyor: Yönetim için artıları ve eksileri hakkında konuşuyorsunuz (riskler). Yönetim bir risk almak istiyorsa, o zaman tamam (kişisel olarak ne düşünürseniz düşünün) ve bundan sonra onların sorumluluğu budur. Ama BT adamlarından biri risklerin ne olduğunu onlara anlatmak zorunda.

Aradığım ilk şey şudur: Yöneticiler eski yazılım risklerini biliyor muydu? Onlara söylendi mi?

Dürüst olmak gerekirse, muhtemelen bu konuda yararlı bir şey bulamayacağınızı hissediyorum, bu yüzden çok fazla zaman harcamam. "Son beş yıldır size söylüyorduk" çizgisinde size yardımcı olabilecek bir şey.

Bu yükseltmeyi gerçekleştirmenin gerçekte ne anlama geldiğini analiz ediyorum. Faaliyetler ve ne kadar sürecekleri ile basit bir elektronik tablo hazırlayın (bilmiyorsanız, size en iyi tahminde bulunun ve kesin olarak bilmediğinizden emin olun). Ancak bu "yükseltme görevi" nin iyi belirtilmediğini unutmayın, bunu düzeltme zamanı / düzeltme fiyatı olarak yapmak imkansızdır.

Bu tür listeler yapmak da tüm sorunu çözmenize yardımcı olacaktır. Bir sonraki şey, risk günlüğü ve ihtiyacınız olan kaynakların listesini oluşturmaktır.

Sonunda, faaliyetler listesi, riskler listesi, ihtiyaç duyduğunuz materyalleri / kişileri listelemeniz gerekir. Tek kelimeyle, yükseltmeyi günlük bir sorun olarak ele almayın, bir PROJE olarak yapın. Bu, şirketinizin akut ihtiyacı üzerinde en azından bir miktar kontrole sahip olmanızı sağlayacaktır.

Hangi aktivitelerin yapılması gerektiğini analiz etmekte sorun yaşıyorsanız, biraz zihin haritası deneyebilir (en sevdiğim sw xMind'dir) ve daha sonra resmi bir belgeye dönüştürebilirsiniz.

Yükseltmenin nasıl yapılacağına dair bazı seçenekleriniz olduğunda, yöneticilerinize maliyet, sonuç ve risk de dahil olmak üzere birkaç cümleyle özetlenmiş olası çözümler (daha fazlası varsa) yazmanız gerekir; ideal olarak tavsiye ettiğiniz seçeneği ve nedenini belirtmek. Çünkü nihai seçim yapmak onların kendisidir - sonuçta yöneticilerdir.

Belki bu özel durumda: Yükseltmenin hiç mümkün olmayabileceğinden bahsedin.

Uzun vadeli strateji yok

Stratejik bir plan oluşturmak artık size yardımcı olmayacak. BT departmanınızda hazırlanmış bir belge ise size hiç yardımcı olmaz. Stratejik plan iş ihtiyaçlarına bağlı olması gereken bir şeydir.

Örnek iş ihtiyacı: İki yıl içinde Çin ve Avustralya'da yeni ofisler açacağız.

BT görevlerinden türetilmiş: Yeni çalışanlara ibadetlerini almaya, yabancı ofislerde altyapı oluşturmaya, yeni çalışanlara (muhtemelen kendi dillerini kullanarak) eğitim sağlamaya, bu ofislerden merkeze güvenli bağlantı sağlamaya,

İşler yolunda giderse, belki ... birkaç ay içinde bir stratejiniz olabilir mi? Yani her şey üzerinde anlaşmaya varıncaya kadar yaklaşık yarım yıl?

Altyapınızı koruma ve belgeleme

Bu geçmişten gelen miras ve şimdi bir şeyleri değiştirmek zorundasınız. Öncelik. Çoğu şeyi güncel hale getirmek için şimdi / yapmak istediğiniz şeylerin bir listesini yapın. Hangisini bekleyebileceğini seçin, kaba bir yol haritası yapın. (Bu yol haritası, sahip olduğunuzda BT stratejinizin bir parçası olmalıdır.)

İyi giden bir şeyi güncellüyorsanız, günlük iş olarak kullanın. Kötü gidebilecek bir şeyle uğraşıyorsanız (harcanan zaman, tahsis edilen insanlar, vb. Açısından "büyük" ise, bir proje olarak ele alın.

Dokümantasyon ve servis bağımlılıkları konusunda size yardımcı olabilecek araçlar vardır - CMDB'ler (örneğin iTop). Ancak işe yaraması biraz zaman alabilir ve yine de bazı dokümantasyon aracına ihtiyacınız vardır. En iyi fikir, herkesin bundan sonra belgelemeye / not almaya başlayabileceği belgeler için bir wiki oluşturmaktır. Yarım saat içinde bir wiki kurabilirsiniz, bu yüzden işleri başlatmak için çok etkili bir yoldur.

Kişisel not: Eski OS işletim sistemini yükseltmek, (muhtemelen kötü / eksik) belgelere değinmeden, büyük bir PITA olacaktır. Sunucuları yeniden yüklemek, uygulamaları taşımak ve her şeyi baştan belgelemek daha kolay değil mi?


Cevabınızı hala daha dikkatli okumalıyım, ama önce. . . Re "Stratejik bir plan oluşturmak artık size yardımcı olmayacak": Şu anki poopstorm'un hikayesi sadece problemin açıklanması amaçlıydı. Bunu köprünün altında su olarak görüyor ve gelecekteki fekal yağışları önlemek için bir tabaka planı oluşturmaya çalışıyoruz . Bunu daha açık hale getirmek için sorumu düzenlemem gerekiyor.
Fing Lixon

1
Evet ne demek istediğini biliyorum. Ama sanırım bu cümleyi kesinleştirirseniz, cevabın geri kalanı hala geçerliliğini korur. :)
Fiisch
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.