Saya bekerja di departemen sistem komputasi CROC, kami mendukung semua yang dapat dibuang ke dinding. Artinya, server, sistem penyimpanan data, dan perangkat keras mahal lainnya di pusat data. Nah, fakta bahwa ia memiliki sistem operasi, infrastruktur dasar. Layanan dasar yang paling sederhana adalah suku cadang, yaitu penggantian komponen tepat waktu. Yang lebih kompleks menggantikan administrator sistem pelanggan.
Momen paling menakutkan dari kontrak adalah penyusunan kerangka acuan. Saya akan memberi tahu Anda tentang kesulitan yang kami rasakan bersama klien dan cara menghindarinya. Nah, saya akan melampirkan contoh template TK yang kita gunakan.
Tingkatkan statistik
Kusen pertama dari semua tugas teknis adalah ketidaktahuan yang dangkal tentang jumlah aplikasi bulanan rata-rata Anda. Ini terlihat seperti ini: Anda ingin melakukan outsourcing administrasi, maka Anda perlu memahami berapa biayanya. Jika Anda hanya melampirkan deskripsi taman peralatan, maka kami sebagai peserta kompetisi akan memperkirakan steker untuk jumlah pekerjaan, kunjungan, jika diperlukan, dan mengirimkan dengan beberapa margin. Tetapi jika Anda tahu persis berapa banyak dan tiket apa yang ada tahun lalu, maka harganya bisa turun secara signifikan - lagipula, Anda dapat melihat sebenarnya apa dan seberapa rusak dan seberapa sering perubahan dilakukan pada infrastruktur. Seseorang, misalnya, menambahkan mesin virtual setiap hari, dan seseorang setahun sekali - harganya akan sama pada perkiraan pertama.
Seringkali tugas pelanggan terlihat seperti "Sekarang atur segalanya untuk kami sekarang". Dan apakah itu? Penyedia layanan (yaitu, bagi kami) tidak memahami volume, semuanya digadaikan kembali untuk biaya tenaga kerja. Jika kami menebus, Anda akan membayar lebih. Jika tiba-tiba harga naik selama kontrak berlangsung, akan ada konflik. Jika tiba-tiba terjadi sesuatu, dan kami mengambil kontrak lebih murah dari yang sebenarnya, maka kami akan berusaha menolak, dan pada akhirnya kami harus mencari kontraktor lagi.
Terkadang pelanggan tidak mengetahui infrastrukturnya sama sekali (misalnya, setelah pengambilalihan merger atau kepergian tiba-tiba dari admin sebelumnya). Dan jika itu adalah cabang, dan mereka sudah lama tidak mencari di sana. Dalam hal ini, Anda perlu melakukan audit di awal. Audit, tentu saja, membutuhkan uang, tetapi menghemat banyak uang untuk kontrak berikutnya. Dan hasil audit tersebut dapat diperlihatkan dalam sebuah kompetisi jika ingin membandingkan pemasok dengan harga per unit jasa. Lagi pula, kami berpikir bagaimana: ada harga pekerjaan (perbaikan, keberangkatan), ada pemahaman berapa banyak dan perangkat apa. Kemudian kita lihat: akan ada begitu banyak kegagalan per bulan untuk unit ini dan itu, kita akan menghabiskan begitu banyak waktu untuk itu. Nah, atau ambil sistem cadangan. Di sini cukup bagi seseorang untuk mengonfigurasi sekali dan hanya memeriksa bahwa semua cadangan berhasil. Dan seseorang tanpa henti mengubah kebijakan, menambah, menghapus,menambahkan lagi. Kami telah mengelola sejak tahun 90-an dan telah mengumpulkan statistik selama ini, jadi kami memprediksi dengan cukup akurat. Dan ketika "ada begitu banyak server dengan isian yang tidak dapat dipahami, beberapa mesin virtual, OS yang tidak dapat dipahami, dan sesuatu yang lain di sana, Anda perlu mengelola, orang itu berhenti" - label harga yang tidak manusiawi dijamin. Apalagi mereka sering datang ke kami dengan membawa peralatan lama, yang sudah lama tidak ada dukungan pabrikan.
Langkah selanjutnya adalah membagi kontrak menjadi pekerjaan biasa dan pekerjaan langka. Intinya begini: jika ini adalah semacam pekerjaan permanen dengan durasi tetap, kami memilihnya di blok terpisah dan menetapkan keteraturan. Untuk tugas yang jarang terjadi, kami membuat daftar sistem solusi yang memerlukan kompetensi (meskipun diperlukan sekali setahun). Kontraktor akan menyiapkan spesialis. Dan itu tidak akan memasukkannya ke dalam daftar harga utama. Dia hanya akan mendaftarkan tarif untuk karya semacam itu.
Contoh favorit saya adalah ketika pelanggan memutuskan bahwa administrasi menyertakan migrasi lengkap layanan tempat situs dijalankan ke pusat data lain pada jarak 1000 km bersama dengan server. Seperti, ambil server dan semua yang diambil bersama mereka (jaringan, penyimpanan, data di dalamnya ...) dan bawa, kami membayar administrasi mereka. Tapi ini agak luar biasa. Biasanya kami memilih hal-hal seperti itu dalam proyek terpisah dan mengerjakan migrasi secara detail.
Waktu reaksi
Saya sering melihat pelanggan yang meresepkan waktu reaksi secara tidak tepat atau tidak meresepkan sama sekali. Lebih baik memperbaiki semuanya di sini sehingga harapan sesuai dengan kenyataan. Sangat penting untuk menulis SLA yang ketat untuk peralatan kritis: kami biasanya memiliki waktu respons 15 menit, penggantian - empat jam. Tetapi jika Anda melakukan ini untuk semua perangkat keras di pusat data, label harga sekali lagi akan menjadi tidak manusiawi. Ada juga kontrak yang lebih kompleks. Kami memiliki fasilitas produksi di mana label harga rata-rata lebih tinggi dari biasanya, tetapi pada saat yang sama kami berlangganan fakta bahwa kami membayar beberapa juta rubel per jam waktu henti. Karena siklus produksi terikat pada node ini. Petugas jaga kami tidak memperhatikan bahwa memori di server penuh atau tertunda di jalan dengan suku cadang - ada kemungkinan, di akhir tahun, tetap berhutang budi kepada pelanggan.
Biasanya produksi, ketika menginginkan pekerjaan satu kali (sebagai kegagalan), mencoba untuk meresepkan SLA selama 15 menit, tidak memahami apa yang ada di baliknya. Untuk mengirim seorang insinyur dengan izin seperti itu, Anda membutuhkannya untuk bertugas sepanjang tahun, dan tidak minum pada Tahun Baru (atau minum secara ketat menurut catur dengan rekan kerja). Dan itu membutuhkan uang - dan sama sekali tidak sebagai layanan satu kali.
Ada kontrak ketika 99% waktu kerja diperlukan, dan mereka membayarnya dengan penalti karena keluar dari indikator. Kami melihat infrastrukturnya, memutuskan bahwa, pada prinsipnya, itu tidak akan mengatasinya, dan segala sesuatu perlu diperbaiki. Kontrak itu tidak termasuk, tapi kami tahu mereka yang memutuskan akan naik. Tidak berhasil.
Pelaporan
Rake favorit ketiga adalah bahwa pelanggan tidak mengatur format pelaporan. Rancang format pelaporan yang ingin Anda lihat. Dan tunjukkan frekuensinya dalam kontrak. Jika semua tugas dilakukan dengan tarif Anda, maka lebih baik kontraktor memberi tahu tentang perkiraan awal durasi pekerjaan sebelum memulai pekerjaan.
Ini untuk pertanyaan "Mengapa Anda memiliki dua jam di sini, dan bukan satu setengah?" Apakah perselisihan abadi. Kami menyelesaikannya sebagai berikut: sebelum memperbaiki, kami memberikan perkiraan kepada pelanggan dengan kesalahan plus atau minus 10% ke samping. Kami menempatkan tugas besar ke dalam proyek dengan rencana kerja dan tenggat waktu panggung.
Jelas bahwa kontrol diperlukan di kedua sisi, yang hanya membuang-buang waktu: kami membiarkan pelanggan masuk ke sistem kami dan secara fanatik memotong laporan sehingga tidak ada kejutan. Karena kami tertarik dengan perpanjangan untuk satu, dua, tiga, dan lima tahun. Dan kami tahu bahwa jika tidak ada perasaan kendali penuh dan dapat diprediksi, tidak akan ada pembaruan kontrak juga.
Menjadwalkan pertemuan rutin juga membantu. Bulan pertama setiap minggu untuk membangun proses, kemudian lebih jarang sehingga pemasok berbagi dengan Anda rekomendasi dari apa yang dilihatnya. Kemudian sebulan sekali, minimal seperempat. Kami memiliki pelanggan yang meninggalkan agen outsourcingnya dalam sebulan, dan dia bahkan tidak tahu. Karena tidak ada dialog. Mereka tidak mendengarkan pelanggan dan melakukan segalanya seperti lima tahun lalu. Artinya, tanpa memperhitungkan kebutuhan bisnis barunya. Pelanggan itu mencoba menyampaikannya, tetapi kemudian dia meludah, mulai mencari kontraktor baru.
Dokumentasi
Rake nomor empat adalah tidak adanya dokumentasi di situs. Ya, saya tahu tidak ada orang yang suka mengubah dokumentasi infrastruktur. Jika Anda tidak menuliskannya di kontrak, maka Anda melakukan sesuatu di sana, membuat ulang sesuatu di sini, tetapi lupa mengatakan - situasi yang umum. Alternatifnya adalah mengajak seseorang yang akan terus memperbaruinya untuk Anda (mengubah sesuatu, mencerminkan). Mudah untuk mengganti penampil atau mentransfer pengiring kembali ke spesialis internal.
Ratusan kali kita datang dari dokumen - hanya DRP sekitar 2011. Dan Anda tidak bisa menggunakannya. Dalam ingatan saya, setidaknya ada dua kasus ketika pelanggan tersebut mengalami masalah produksi. Mereka membantu mencari tahu ada apa, ternyata DRP tidak berfungsi, karena IP sudah berubah.
Jangan lupa untuk melakukan bongkar muat di akhir periode
Agen outsourcing tingkat lanjut memelihara CMDB: memasang peralatan baru, menambahkannya ke pangkalan. Semuanya selalu diperbarui. Jika tidak ada basis CMDB-nya sendiri, organisasi layanan selalu memilikinya. Nah, jika ini bukan tentang Anda, mintalah akses ke sana. Dan pastikan untuk menambahkan klausul ke kontrak - sehingga data yang terkumpul kemudian akan ditransfer kepada Anda pada saat pengakhiran kontrak. Kami memiliki pelanggan yang senang bahwa dia diikuti dimana jaminan apa, lisensi mana. Tetapi ketika kontrak berakhir, saya harus segera menginventarisir semuanya sendiri. Ini adalah layanan pertama kami bersama dengan audit - rekanan sebelumnya tidak ingin membagikan data.
Jangan takut untuk memasukkan denda tinggi dalam kontrak Anda
Seorang pemain normal memperlakukan mereka dengan baik. Kesediaan untuk berlangganan merupakan indikator bahwa pemasok yakin dalam mematuhi SLA. Satu-satunya poin adalah jika Anda mentransfer kendali langsung atas penurunan produktivitas dan memperbaiki persentase ketersediaan, buatlah, misalnya, satu bulan untuk periode transisi ketika penalti tidak berlaku. Diperlukan waktu satu bulan untuk mempelajari infrastruktur TI, memperbarui dokumentasi, mendapatkan semua akses, dan kemudian menjamin ketersediaannya. Jika seseorang berlangganan tanpa itu, infrastruktur Anda terancam untuk bulan pertama.
Ngomong-ngomong, Anda juga perlu mengukur apa yang menurut Anda merupakan tingkat kinerja normal tepat di infrastruktur tempat tinggal. Kemudian akan ada sesuatu untuk dibandingkan dan menunjukkan kepada pelaku bahwa produktivitas telah menurun. Jika tidak, Anda tidak akan membuktikannya.
Segera libatkan spesialis keamanan informasi dalam proses pengembangan
Ini sangat penting sehingga sering mendefinisikan proyek secara umum. Mari sekali lagi: segera libatkan spesialis keamanan informasi dalam proses pengembangan. Jika Anda tiba-tiba tidak melakukan ini, mengharapkan masalah. Paling sering, mereka dikelola dari jarak jauh, jadi pemasok perlu memahami apa saja persyaratannya. Misalnya, ada klien yang pengawasan video dari stasiun kerja khusus tempat koneksi dibuat sangat penting. Bank bahkan lebih serius - mereka memiliki GOST langsung dan persyaratan Bank Sentral. Cara terbaik untuk membuat spesifikasi teknis, yang secara dramatis akan menaikkan harga, adalah dengan langsung mengacu pada peraturan internal di dalamnya dan tidak menyediakannya.
Kami punya kasus ketika mereka tidak bisa menandatangani kontrak selama tiga bulan, CIO menutup telepon. Petugas keamanan menginginkan penerapan GOST, kami ingin dia menunjukkan bagaimana penerapannya sekarang (mencurigai bahwa itu tidak mungkin), dan menawarkan untuk mengirim varian. Dia tidak mengirim. Akibatnya, mereka menulis bahwa "jika dalam tiga hari Anda tidak menerima komentar atas teks yang diusulkan dari kerangka acuan, maka kami menganggap itu setuju," dan mencantumkan kepala perusahaan dalam salinannya. IB mengirimkan satu kalimat: "Pemasangan pembaruan dan tambalan yang menghilangkan kerentanan kritis IS harus dilakukan tidak lebih dari 48 jam." Dan itu saja. Bisa dikatakan sudah berlalu.
Secara umum, topik keamanan informasi licin dan licin. Orang yang aman hidup di dunia mereka sendiri. Semuanya sejuk dan sejuk, spesialis infrastruktur sepakat di antara mereka sendiri, kontraktor menerapkannya. Dan kemudian Anda datang ke perusahaan, dan Anda: pergi ke departemen pertama untuk bernegosiasi. Dan di sana mereka duduk di bangku dan mengajukan pertanyaan, karena tidak ada yang memberi tahu mereka bahwa sesuatu sedang terjadi.
Oh ya, dan jangan lupa perhatikan bahwa admin harus punya akses ke objek tersebut. Dan sulit untuk mengubah bagian di server dari jarak jauh. Kami memiliki salah satu proyek yang menunggu selama lima hingga enam jam karena fakta bahwa tim global perusahaan (kepala TI di India) perlu menyetujui permintaan akses fisik seorang insinyur.
Meja layanan penting
Jika Anda ingin melihat aplikasi online, jangan terlalu malas untuk mendaftar kemungkinan mengintegrasikan sistem Service Desk Anda dengan kontraktor atau membutuhkan portal web. Dengan cara ini Anda dapat mengontrol eksekusi secara transparan. Banyak pelanggan yang bekerja melalui surat hanya menerima pesan "Tiket Anda sangat penting bagi kami, dan kami akan segera menanganinya." Dan hanya itu, di luar kotak hitam. Dan jika kasusnya kritis, semua orang ingin melihat prioritas, mereka ingin melihat siapa yang bekerja, microstats. Beberapa meminta untuk menelepon setiap sepuluh menit. Sekarang kami memiliki orang yang berdedikasi yang berdiri di samping insinyur, tidak mengganggu penyelesaian masalahnya, tetapi pada saat yang sama memberi tahu pelanggan tentang status kasus kritis, ketika semuanya sudah selesai, tidak ada yang berfungsi dan semua orang gugup.
Itu juga sangat keren di satu bank, di mana aturan untuk menanggapi insiden dijelaskan dalam standar internal. Untungnya, mereka memberikannya kepada kami. Ada 300 halaman, ditulis kembali pada tahun 2005 dan diperbarui pada tahun 2018 di atas satu set kruk. Secara umum, antara lain, logis, terdapat prosedur untuk menanggapi insiden dengan kumpulan obrolan dari orang-orang penting secara eksklusif di Skype. Di malam hari, Anda perlu menelepon semua yang tertarik dan berhenti berlangganan di sana. Dan Skype tidak terlalu hidup. Saya harus menginstal ulang.
Sertifikat tidak boleh ada di perusahaan, tetapi di spesialis proyek Anda
Saran sederhana: pastikan profesionalisme kontraktor, ini adalah sertifikat dan pengalaman kerja di perusahaan.
Tip yang lebih sulit adalah memastikan bahwa orang-orang ini akan ada di proyek Anda. Ada perusahaan yang menyurati langsung ke TK yang bisa dilibatkan dalam pekerjaan ada yang tidak bisa. Trainee tidak cocok untuk bekerja dengan sistem kritis. Anda dapat menulisnya seperti ini: "Pengujian spesialis oleh spesialis kami." Saya telah melihat seorang pria datang ke sepotong besi dengan seikat instruksi. Katanya: "Mereka menemukan saya di Yuda seharga 5 ribu rubel."
Kebetulan mereka memberikan daftar keren, menang, orang-orang datang ke pertemuan awal - dan ada orang lain yang tidak berpartisipasi, tidak ada beberapa kompetensi yang diperlukan. Saya tahu bahwa ada kasus di pasar ketika tim diganti tiga kali. Di bidang keuangan, prosedurnya sederhana: ada daftar siapa yang bisa menyentuh infrastruktur. Mereka tidak menerima siapapun begitu saja, hanya di daftar putih.
Akhirnya
Tuliskan semua kebutuhan Anda, jenis pekerjaan, jenis aplikasi dan buat formulir di XLS dengan ketidakmampuan untuk mengedit kolom. Karena sangat sering pemasok mencoba menulis sesuatu tentang mereka sendiri, dan tidak mungkin untuk membandingkan lebih jauh. Saya tahu nasihatnya sederhana, tetapi jarang ada yang menggunakannya. Dan kemudian segunung waktu terbuang untuk mencari tahu siapa yang menjanjikan apa dan siapa yang lebih menguntungkan harganya.
Proyek sampel
Kami mendukung perusahaan ritel dengan toko di semua wilayah Rusia (jumlah toko meningkat sebesar 13% sepanjang tahun). Infrastruktur terdiri dari 1.400 posisi dari produsen yang berbeda, dan fungsi yang penting untuk bisnis beroperasi pada dasarnya. TI menanggung sejumlah besar tugas pengembangan. Di sana, bahkan dukungan infrastrukturnya begitu besar sehingga departemen TI sendiri tidak dapat mengatasinya. Ada banyak peralatan, perlu untuk mengatur siklus hidupnya. Secara umum, mereka telah melakukan outsourcing tugas rutin selama lima tahun. Kami telah bersama mereka selama dua tahun. Dalam tugas:
- 24 x 7 pemantauan infrastruktur komputasi dan lingkungan virtualisasi.
- Menginformasikan pihak yang bertanggung jawab atas masalah berdasarkan hasil pemantauan, untuk kasus kritis dalam waktu 15 menit.
- Masuknya aplikasi untuk penggantian suku cadang dari produsen, penggantian, menginformasikan tentang pemulihan pekerjaan.
- , / .
- 1400 CMDB.
- , CMDB.
Kami memiliki tim: baris pertama bertanggung jawab untuk memantau dan mengajukan aplikasi dari vendor, baris kedua untuk pekerjaan lapangan, yang ketiga untuk bidang terkait (ketika perangkat lunak aplikasi tidak berfungsi, dan tidak jelas di mana masalahnya). Ada seorang manajer teknis yang berdedikasi, dia mengawasi dan mengoordinasikan semua spesialis teknis; bertanggung jawab secara terpisah atas CMDB; manajer layanan terpisah bertanggung jawab atas koordinasi proyek secara keseluruhan.
Tentang kontrak. Saya harus segera mengatakan bahwa itu berisi SLA untuk semua pekerjaan, serta hukuman untuk tidak terpenuhi. Ada kemungkinan revisi triwulanan dari daftar peralatan yang didukung dengan penghitungan ulang biaya yang mudah, karena ada daftar harga untuk setiap unit. Kami juga mengadakan pertemuan rutin dengan pelanggan, di mana kami membahas hasil pekerjaan dan rencana untuk masa depan.
Hasilnya adalah penghematan 5500 jam per tahun bagi pelanggan, yang dihabiskan oleh karyawan mereka sendiri untuk proyek pengembangan. 99,9% dari pemenuhan SLA (ada dua pelanggaran di bulan pertama dalam hal persyaratan pemberitahuan, yang diperbaiki karena umpan balik reguler). Jumlah notifikasi dari sistem pemantauan menurun hingga 30%, berkat pengaturan yang optimal. Ketika ditanya tentang bagaimana kami bekerja, CIO menjawab: "Kami tidak mendengar tentang Anda." Dia mengerti betapa pentingnya ini.
Template TK di sini . Ada 16 halaman birokrasi yang mengerikan, yang akan menyelamatkan saraf semua pihak dan ratusan jam kerja, jika Anda membaca dan berdiskusi sekali sebelum menandatangani.