Menü

İletişime geçin
Logo
Basın

OTOKO® ile Bulut Geçişi

Bulut geçişi, körlemesine değil.

Bir uygulama, yalnızca yeni konumda oturum açma, arayüzler, veriler ve günlük iş akışları da çalıştığında taşınmış sayılır. Bu nedenle OTOKO®, Azure, Telekom T Cloud veya başka uygun bir platforma giden yolu iş süreçlerinizden yola çıkarak planlar. Birbiriyle ilişkili sistemler; hazırlanmış testler, geçişe ilişkin net kararlar ve planlı bir devirle, koordineli adımlar halinde taşınır.

Sizin için üstlendiklerimiz
Birden fazla rack arasındaki ağ bağlantıları, temsili görsel
Bulut Geçişi

OTOKO® tarafından planlama, uygulama ve üzerinde anlaşılan işletim

Temsili görsel · sağlayıcı tesisine ait bir çekim değildir

OTOKO®'ya verdiğiniz görev

Taşımayı sunucu listelerine göre değil, uygulamalara göre planlamak.

Bir veri merkezinin fesih tarihi bellidir, ancak veritabanları, dosya paylaşımları ve iş uygulamaları birbirinden bağımsız olarak taşınamaz. Bir zaman planının güvenilir olabilmesi için önce bu bağımlılıkların bilinmesi gerekir. Aynı derecede önemli olan, uygulamaların iş açısından doğru çalıştığını kimin onaylayacağı ve bir geçişin hangi koşullarda geri alınacağıdır.

Bizden talep edebilecekleriniz

Envanter çıkarma aşamasından sistemin kararlı hale gelmesine kadar, üzerinde anlaşılan geçiş adımlarını koordine ederiz. Hedef ortam, aktarım ve teknik testler tanımlanmış görev kapsamı içinde yer alır; uygulama sorumlularınız iş açısından kontrole ve kabule katılır. Taşımanın ardından açıkta kalan görev olmaması için devre dışı bırakma ve devir en baştan planlamaya dahil edilir.

Hizmetlerin ayrıntıları

Hizmet kapsamı

Her geçiş dalgası sağlam bir hazırlık gerektirir.

Envanter çıkarma, hedef kararı ve geçiş birbiri üzerine kurulur. Testler ve devir bu sırada erkenden planlanır; böylece iş birimi kabulleri ve sonrasındaki kaldırma işlemleri ancak aktarımdan sonra netleştirilmek zorunda kalmaz.

Birlikte taşınması gereken sistemleri belirlemek

Veritabanları, dizin hizmetleri ve arayüzler, hangi sistemlerin birlikte taşınması gerektiğini belirler. Envanter çıkarma çalışmasından yola çıkarak geçiş grupları oluşturur ve her gruba bir irtibat kişisi atarız. Veri hacimleri, bakım pencereleri ve iş açısından yapılacak kontroller, aktarımdan önce her grup için netleştirilir.

Ekibiniz bunlarla çalışmaya devam eder

Belirlenmiş sahipleri olan geçiş grupları ve bir bağımlılık özeti.

Teknik uygulama

Keşif ve bağımlılık haritalama

Sunucuları, veritabanlarını, kimlikleri ve arayüzleri birbiriyle bağlantılı iş yükleri olarak tespit ederiz. Lisans koşulları ve kullanılabilir bakım pencereleri planlamaya dahil edilir. Eksik bilgiler, sessizce önemsiz kabul edilmek yerine risk olarak belgelenir.

Doğru taşıma yolunu belirlemek

Değiştirmeden aktarmak, platform hizmetlerinden yararlanmak veya önce modernize etmek: uygun yol, uygulamaya bağlıdır. Seçeneklerin gerektirdiği uyarlamaları, işletime etkilerini ve risklerini birlikte değerlendiririz. Efor ve sıralamanın anlaşılır kalması için karar her sistem için ayrı ayrı belgelenir.

Ekibiniz bunlarla çalışmaya devam eder

Ön koşulları ve hedef işletim modelini içeren, her iş yükü için bir geçiş stratejisi.

Teknik uygulama

Rehosting, replatforming veya modernizasyon

Büyük ölçüde değişmeden yapılan bir taşınmayı, hedef platforma yönelik uyarlamalardan ve daha kapsamlı bir modernizasyondan ayırırız. Azure Migrate veya platforma özgü araçlar bu süreci destekleyebilir. Hangi yöntemin uygun olduğuna veri bağımlılıkları, işletim gereksinimleri ve efor karar verir.

Geçişi hazırlamak ve gerçekleştirmek

Geçiş gününde birçok adımın birbirine uyması gerekir. Üzerinde anlaşılan bir süreç; veri aktarımını, kontrolleri, onayları ve iletişimi tanımlar. Geri dönüş kriterleri de önceden belirlenir, böylece teknik ve iş birimi sorumluları ne zaman harekete geçmeleri veya karar vermeleri gerektiğini bilir.

Ekibiniz bunlarla çalışmaya devam eder

Sorumluları, testleri ve iletişim yollarını içeren, üzerinde anlaşılmış bir geçiş runbook'u.

Teknik uygulama

Geçiş dalgaları ve nihai geçiş

Veri aktarımı, senkronizasyon ve geçiş, bir runbook'u izler. Teknik testleri ve iş testlerini, iptal kriterlerini ve gerçekçi bir geri dönüş planını birlikte kararlaştırırız. Kesintisiz bir geçiş genel geçer biçimde vaat edilmez; olası kesinti süreleri her uygulama için ayrı planlanır.

Taşımanın ardından toparlamak ve devretmek

Üretime geçişin ardından izleme, tamamlayıcı çalışmalar ve kabul süreci gelir. Eski ortamın devre dışı bırakılması ancak bundan sonra kararlaştırılır. Devir; yeni yapılandırmaları, işletim sorumluluklarını ve açık görevleri kayıt altına alır. Bu sırada paralel çalışan kaynaklar ve bunların maliyetleri görünür kalır.

Ekibiniz bunlarla çalışmaya devam eder

Kabul tutanağı, güncellenmiş dokümantasyon ve kontrollü bir devre dışı bırakma planı.

Teknik uygulama

Stabilizasyon ve devre dışı bırakma

Geçişten sonra işletim verilerini ve iş süreçlerini inceleriz. Eski kaynaklar ancak kabulden sonra kapatılmak üzere planlanır. Paralel ortamların sürekli olarak gereksiz maliyet oluşturmaması için saklama süreleri, lisanslar ve kalan arayüzler dikkate alınır.

Planlama ve uygulama ayrıntıları

Bulut geçişini iş süreçleri geride kalmayacak şekilde hazırlamak.

Bir taşıma, veri yollarını, erişimleri ve işletim süreçlerini aynı anda değiştirir. Bu nedenle karmaşıklığı yalnızca sunucu sayısına bakılarak değerlendirilemez. Sağlam bir planlama, teknik bağımlılıkları iş açısından kontrollerle ve geçiş sırasında alınması gereken kararlarla birlikte ele alır.

Bağımlılıkları belirlemek ve uygun geçiş dalgaları oluşturmak

Bir uygulama, ilk sistem listesinde görünmeyen bileşenlere bağlı olabilir: dizin hizmetleri, planlanmış arka plan görevleri, dosya paylaşımları veya harici bir ortağın arayüzü. Bu tür bağlantılar sorumlu kişilerle birlikte tespit edilir. Bundan, bileşenleri birlikte taşınan veya geçiş dönemi boyunca bilinçli olarak birbirine bağlı tutulan geçiş grupları oluşturulur. Veri hacmi, bakım pencereleri ve mevcut iş birimi irtibat kişileri sırayı etkiler. Dalga planı böylece yalnızca teknik olarak taşınabilir sistemlerin bir listesini değil, gerçek süreçleri yansıtır.

Her grup için uygun bir geçiş yolu belirlenir. Bazı uygulamalar başlangıçta büyük ölçüde değiştirilmeden taşınabilirken, diğerleri hedef ortamda uyarlamalar gerektirir. Taşımayı gereksiz yere büyütecekse, daha kapsamlı bir modernizasyon ayrı bir adım olarak anlamlı olabilir. Karar, geçiş riskini, sonraki işletimi ve mevcut kaynakları dikkate alır. Aktarımdan önce hedef ortam, erişimler ve gerekli bağlantılar kontrol edilir, böylece bilinen ön koşulların planlanan geçiş penceresinde son anda oluşturulması gerekmez.

Geçişi, iş birimi kabulünü ve geri dönüşü birlikte planlamak

Geçiş gününde veri durumu, erişimlerdeki değişiklikler ve iş açısından kontroller birbiriyle uyumlu olmalıdır. Bu nedenle kararlaştırılmış bir akış, eski sistemdeki çalışmanın ne zaman sona erdiğini, hangi verilerin aktarılacağını ve ardından hangi testlerin yapılacağını tanımlar. Buna irtibat kişileri ve iletişim yolları da dahildir. Paydaşlar, bir sorunu kimin değerlendireceğini ve devam kararını kimin vereceğini bilmelidir. Teknik erişilebilirlik burada yalnızca bir kontrol adımıdır; uygulamanın ayrıca iş faaliyetleriniz için önemli olan işlemleri de yürütebilmesi gerekir.

Geçişin hangi koşullarda iptal edileceği veya geri alınacağı da önceden görüşülür. Özellikle hedef sistemde zaten yeni veriler oluşmuşsa, geri dönüş her uygulama için aynı derecede kolay değildir. Bu nedenle planlama, öngörülen yöntemin ön koşullarını ve sınırlarını kayıt altına alır. Pilot uygulama ve testler, varsayımları kontrol etmeye ve süreci iyileştirmeye yarar. Bir sonraki geçiş dalgasının hazır olup olmadığı veya ek çalışmanın gerekli kalıp kalmadığı ancak bu sonuçlarla birlikte değerlendirilebilir.

Stabilizasyonu ve devre dışı bırakmayı projenin bir parçası olarak ele almak

Üretime geçişten sonra yeni gözlemler ortaya çıkabilir: değişen yük, eksik yetkiler veya testte tam olarak görünür olmayan süreçler. Kararlaştırılan stabilizasyon aşamasında bu tür noktalar tespit edilir, değerlendirilir ve giderilir. İşletime devir, yapılandırmayı, erişimleri, izlemeyi ve bilinen kalan görevleri kapsar. Uygulama sorumlularınız iş açısından kullanılabilirliği onaylar; teknik ve organizasyonel sorumluluklar, proje sona erdikten sonra yeni bildirimlere kimin yanıt vereceğinin net olacağı şekilde belgelenir.

Eski sistemler bundan sonra gözden geçirilmeden çalışmaya devam etmemelidir. Aynı zamanda devre dışı bırakma işlemi, hâlâ gerekli olan hiçbir bağımlılığı ortadan kaldırmamalıdır. Bu nedenle kabulden sonra hangi kaynakların durdurulacağı, hangi verilerin saklanacağı ve hangi sözleşmelerin uyarlanması gerektiği birlikte belirlenir. Bir devre dışı bırakma planı sırayı ve onayları kayıt altına alır. Böylece çift maliyetler ve açık görevler görünür kalır. Geçiş, verilerin artık başka bir yerde bulunduğunun yalnızca tespit edilmesiyle değil, düzenli bir devir ve kararlaştırılmış takip çalışmalarıyla sona erer.

Birlikte şöyle çalışıyoruz

İşinizi siz bilirsiniz.
Üzerinde anlaşılan bulut işini biz üstleniriz.

Her teknik adımı kendiniz düzenlemeniz gerekmez. Görevleri ve kararları kayıt altına alır, bilgisine veya onayına ihtiyaç duyulan noktalarda ekibinizi sürece dahil ederiz.

01

Geçiş gruplarını belirlemek

Uygulamalar ve bağımlılıklar, birlikte taşınacak gruplar halinde bir araya getirilir. İrtibat kişileri, veri hacmi ve bakım pencereleri dalga planını belirler.

Sizin katkınız: İş tarafındaki sorumluları ve işletim açısından önemli tarihleri belirtin.

02

Geçişe birlikte karar vermek

Aktarım ve teknik kontroller, üzerinde anlaşılmış bir sürece göre yapılır. Onaydan önce sonuçlar ve olası geri dönüş kriterleri birlikte değerlendirilir.

Sizin katkınız: Uygulama ekibiniz iş birimi testlerini onaylar ve geçiş kararına katkıda bulunur.

03

İstikrara kavuşturmak ve eski sistemleri devre dışı bırakmak

Üretime geçişten sonra açık noktalar ele alınır ve işletim dokümantasyonu devredilir. Eski kaynakların kaldırılması kabulün ardından gerçekleşir.

Sizin katkınız: Kullanılabilirliği teyit edin ve artık gerekli olmayan sistemlerin üzerinde anlaşılmış şekilde hizmetten kaldırılmasını onaylayın.

OTOKO®'nun Köln ofisindeki toplantı odası

Örnek proje senaryosu

Bir müşteri portalı buluta geçiyor

Ortak bir proje şöyle görünebilir. Somut kapsam, başlangıç durumunuzdan ortaya çıkar.

  1. Başlangıç durumu

    Web uygulaması, veritabanı ve dahili kullanıcı yönetimi birbirine bağlı. Süregelen satış faaliyetleri portala ihtiyaç duymaya devam ediyor.

  2. Yaklaşımımız

    Hedef ortamı test eder, verileri senkronize eder ve geçişi teknik testler ve iş birimi testleriyle planlarız.

  3. Hedef durum

    Kabul ve geri dönüş seçeneği içeren belgelenmiş bir geçiş, sonraki işletim için anlaşılır bir temel oluşturur.

Elde ettikleriniz

Ekibinizin üzerinde
çalışmaya devam edeceği sonuçlar.

  • Her uygulama için migrasyon yolu içeren değerlendirilmiş uygulama portföyü

  • Kabul kriterleri ve geri dönüş planlarıyla dalga planı

  • Her dalga için veri karşılaştırmalı migrasyon kaydı

İlgiden somut iş kapsamına

Projenizi böyle
hazırlıyoruz.

Ön görüşme için bu belgelerin henüz eksiksiz olması gerekmez. Neyin mevcut olduğunu ve değerlendirmenin hangi bilgileri tamamlaması gerektiğini birlikte netleştiririz.

Başlangıç için yararlı olanlar

  • Taşınacak uygulamaların envanteri ve irtibat kişileri
  • Veri hacmi, arayüzler ve bakım pencereleri
  • İstenen hedef platform ve mevcut sözleşmeler

Somut teklif böyle hazırlanır

Hizmet kapsamı, ekibinizin katkısı, gereken erişimler, kabul kriterleri ve devir teklifte belirtilir. Sağlayıcı ücretleri, proje hizmetleri ve sürekli işletim açık şekilde birbirinden ayrılır.

Değerlendirmeyi görüşün

Başlamadan önce

Sorularınız.
Net yanıtlar.

Bulut Geçişi kapsamında neler elde ediyoruz?

Her uygulama için migrasyon yolu içeren değerlendirilmiş uygulama portföyü. Kabul kriterleri ve geri dönüş planlarıyla dalga planı. Her dalga için veri karşılaştırmalı migrasyon kaydı. Kapsamı ve kabul kriterlerini başlangıçta birlikte belirleriz.

Mevcut bir ortamla başlayabilir miyiz?

Evet. Mevcut uygulamalarınızı, arayüzlerinizi ve işletim süreçlerinizi inceler, gereken değişikliklerin kapsamını sizinle birlikte belirleriz. Her şeyin baştan kurulması otomatik olarak gerekmez.

Efor ve sorumluluk nasıl belirlenir?

Envanter çıkarma çalışmasının ardından iş paketlerini, sorumlulukları, kabul kriterlerini ve devri birlikte belirleriz. Bunun sonucunda somut proje kapsamı için bir teklif hazırlanır.

Kesintisiz bir geçiş mümkün müdür?

Bu, uygulamaya, veri saklama biçimine ve aktarım yöntemine bağlıdır. İzin verilebilir kesintileri planlar ve uygun senkronizasyonu inceleriz. Bir değerlendirme yapılmadan verilecek genel bir sıfır kesinti vaadi güvenilir olmaz.

Taşıma öncesinde bir Landing Zone hazır olmalı mıdır?

Kimlikler, ağ, kayıt tutma ve işletim için gereken hedef temel, üretime geçmeden önce hazır olmalıdır. Kapsam ve genişleme düzeyi, ilk iş yüklerine ve sonraki plana göre belirlenir.

OTOKO® ile Bulut Geçişi

Geçişinizin takvimini hangi tarih belirliyor?

Bir sözleşmenin sona ermesi veya planlanan bir kapatma, görüşme için iyi bir başlangıç noktasıdır. Uygulama listenizle birlikte bu tarih, bağımlılıkları ve ön hazırlıkları erkenden değerlendirmeye ve gerçekçi bir kapsam belirlemeye yardımcı olur.

Bulut Geçişi hakkında ön görüşme

İş Ortaklarımız

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Erişilebilirlik

Görünümü ihtiyaçlarınıza göre ayarlayın.

Bu sayfa için henüz basit dil sürümü mevcut değil.

Ayarlar şu anda yalnızca bu ziyaret için geçerlidir. Ayarların kalıcı olarak kaydedilmesine Çerez ayarları bölümünden izin verebilirsiniz.