Hari ini kami melanjutkan serangkaian posting tentang pekerjaan tim dukungan teknis, yang dimulai pada saat itu dengan
Loxmatiymamont dalam
artikel tentang dukungan Veeam .
Apa yang tampaknya menjadi Dukungan Teknis? Duduklah sendiri, selesaikan masalah teknis, Anda adalah yang paling cerdas, paling berpengetahuan, Anda adalah Insinyur yang paling tepat bagi Pengguna yang Takut. Mereka membawa ketakutan, rasa sakit, masalah, dan Anda memutuskan, membantu, memberi nasihat, dan, pada akhirnya, Pengguna membuat Anda tidak Takut, tetapi Terinspirasi.
Sudahkah Anda merasakan pentingnya karya ini, prinsip-prinsip filosofis dan pedagogis yang terkandung di dalamnya?
Jadi, semuanya sedikit berbeda. Dukungan teknis, pertama-tama, Dukungan, dan kemudian Teknis, dan oleh karena itu semua pekerjaan adalah 99% persen tentang orang dan komunikasi dengan mereka, jadi tentu saja kita ada hubungannya dengan misanthropes bertekstur dan introvert patologis, tetapi akan sulit - kali ini, dan dua orang tidak selalu dapat diprediksi, dan karena itu, bekerja dalam Dukungan Teknis, Anda dapat belajar, melihat dan mendengar banyak hal menarik dan tidak biasa. Di bawah potongan, saya akan berbagi dengan pembaca beberapa cerita seperti itu.
Kisah detektif pertama: Dukungan Veeam dan belasan hari yang hilang
Latar belakangnya adalah sebagai berikut: server NTP (yang bertanggung jawab untuk menyinkronkan waktu di jaringan) macet dengan klien, dan waktu melompati host yang tidak terduga. Tentu saja, ini tidak berlaku untuk Veeam, dan klien, sebagai spesialis yang kompeten secara teknis, memutuskan semuanya sendiri, tetapi: klien yang menggunakan Veeam mendukung server MariaDB-nya, dan dengan skrip yang terpisah melakukan dump dasar dan cadangan log biner. Setiap hari
Setelah berurusan dengan NTP, klien memeriksa cadangan yang dibuat oleh perangkat lunak kami dan melihat hal yang mengerikan: 12 hari cadangan log biner menghilang di suatu tempat, dan laporan tugas menunjukkan keberhasilan. Setiap hari
Untuk memecahkan misteri ini mereka memanggil kami.
Investigasi cepat membawa kami ke penyebab utama, yang ternyata server NTP yang sama. Bagaimana?
Dan begini caranya: selama waktu melonjak, server NTP dengan murah hati memakai server pada hari-hari pertama September pemberontakan petani di Normandia, subordinasi Kashmir oleh Afghanistan dan awal pembangunan garis berbenteng Tobolo-Ishim di Kekaisaran Rusia - yaitu, tahun 1752 dari kelahiran Kristus. Dengan tingkah aneh sejarah, pada bulan September tahun ini Inggris Raya dan koloni-koloni Amerika Utaranya memutuskan untuk beralih ke kalender Gregorian, dan karenanya bulan itu terlihat seperti ini:
Jadi baik dump basis dan cadangan log biner benar-benar dilakukan setiap hari, hanya hari-hari ini pada 1752 ternyata tepat 12 kurang dari biasanya, dan log untuk 3 September adalah tanggal ke empat belas, keempat ke lima belas, dan seterusnya.
Masalah yang sama terwujud ketika pengguna menggunakan kalender Hijra - dalam hal ini, pencadangan berjalan tanpa hambatan, dan ketika mengembalikan data, layanan dengan keras kepala menjadi gila mencoba bekerja dengan database yang dibuat pada sekitar 1400.
Tetapi tidak selalu masalah dari waktu ke waktu - ini adalah masalah perangkat lunak: begitu insinyur kami harus membuktikan kepada klien dua minggu bahwa hari kedua minggu itu adalah Selasa, tetapi bukan Kamis, di mana klien, seorang borjuis Eropa yang sepenuhnya terhormat, menolak untuk percaya sama sekali.
Kisah kedua - komedi lokasi geografis: Dukungan Veeam dan 20 ribu liga di atas air
Sebuah cerita yang dengan sendirinya memprovokasi jika bukan senyuman, maka kedutan yang membingungkan dengan satu alis pasti.
Klien untuk waktu yang lama menderita masalah dalam semua tugas cadangannya: mereka meninggal berulang kali, seperti halnya layanan utama yang memantau pekerjaan mereka. Insinyur itu, yang menangani masalah itu, dengan cepat mengetahui: sebelum setiap episode, waktu dalam log kami melonjak selama satu jam, sekarang ke masa lalu, kemudian ke masa depan. Alasannya diketahui hanya dengan bertanya pada klien.
Percayalah pada penjelasan dan tekan pertanyaan "mengapa?" ternyata jauh lebih rumit.
Bayangkan: sebuah kapal pergi ke suatu tempat di Samudra Atlantik. Perangkat lunak kami diinstal di atasnya, dan skrip kecil berputar berikutnya, melacak koordinat GPS kapal. Setiap kali kapal melintasi zona waktu berikutnya, skrip mengubah waktu di semua server dan layanan, termasuk milik kami, dan terlebih lagi, untuk memastikan bahwa semua orang bekerja dengan waktu yang tepat, kapal juga memuat ulang beberapa layanan. Contoh yang baik dari solusi kreatif dengan gaya "kami memecahkan satu masalah dengan mengorbankan dua lainnya").
PS Dalam proses mengerjakan artikel ini, saya diingatkan tentang server surat Dovecot dan metode penanganan situasi yang serupa:
Fatal: Waktu baru saja mundur 7 detik. Ini mungkin menyebabkan banyak masalah, jadi saya akan bunuh diri sekarang. (Kesalahan katastropik: transfer waktu terjadi 7 detik yang lalu. Ini dapat menyebabkan banyak masalah, jadi saya baru saja membersihkan diri.)Kisah Tiga - "Horor": Dukungan Veeam dan Boiler Meledak
Seorang teman dari AS yang memanggil kami menderita untuk waktu yang sangat lama dari hang layanan Veeam-nya dan juga tidak ingin mencoba reboot yang ditawarkan untuk alasan mistis (waktu mesin pada saat itu telah dihitung selama bertahun-tahun) sampai akhirnya dia menyerah dan menjelaskan alasan perlawanannya:
“Anda tahu, pada mesin ini dengan Windows 7, tidak hanya Veeam yang berputar, tetapi juga pengontrol dari Rumah Pintar: semua kamera, sensor, pencahayaan, alarm, dan segalanya. Terakhir kali kami menyalakannya kembali, sebuah ketel meledak. ”
Kisah Keempat, Mistis: Dukungan Veeam dan Mata Surga
Kami memiliki teknologi Surebackup, yang memungkinkan Anda untuk menjalankan pencadangan di lingkungan yang terisolasi dan memeriksa seberapa suksesnya mereka, tidak hanya dalam laporan, tetapi juga dalam kenyataan (dan jika mereka berubah menjadi labu dengan persentase pekerjaan terakhir selesai). Teknologi yang baik, cukup andal, dibangun berdasarkan penggunaan beberapa skenario pengujian, termasuk memeriksa ketersediaan melalui jaringan (misalnya, memeriksa port aplikasi).
Untuk bekerja dengan jaringan yang terisolasi, kami menjalankan aplikasi terpisah (mesin virtual kecil), yang hidup sebagai gateway dan sebagai alat kerja utama dari semua tes - dan di sini ada yang salah.
Peralatan diluncurkan dengan sukses, tetapi kami tidak dapat terhubung sendiri - setelah beberapa saat port jaringan ternyata tidak tersedia. Pemindaian siklik dari port alamat IP dengan cepat menunjukkan bahwa kadang-kadang port kita, dan kadang-kadang tidak, tetapi port TCP 544 muncul dari suatu tempat, yang seharusnya tidak ada secara teori. Kami mencoba alamat lain - pengulangan skrip, kami memeriksa arp - alamat mac berbeda.
Dalam kebingungan lengkap, buka alamat dengan browser web dan kaget melihat login beberapa kamera web Cina. Sekali lagi, kami mengubah alamat IP untuk aplikasi, dan kami mendapatkan gambar yang persis sama - untuk beberapa alasan, semua alamat IP pada jaringan akan mengarahkan ke kamera ini, yang tidak dipahami oleh kami maupun klien.
Teka-teki itu tetap tidak terselesaikan.
***
Apakah Anda pikir ini adalah contoh yang terisolasi? Insinyur mana pun yang diambil secara tidak sengaja dapat memberi tahu Anda tentang selusin cerita semacam itu, tanpa terlalu menegangkan dan tidak pernah mengulanginya.
Inilah yang memberi kami rasa dan dorongan untuk bekerja. Kisah-kisah seperti itu membantu untuk mengingat bahwa tidak semua pekerjaan kami menghasilkan solusi kering untuk masalah teknis, ia memiliki komedi dan drama, teka-teki dan tantangan. Ini sumber daya kami. Inilah yang membantu kita untuk memenuhi setiap panggilan tidak dengan lelah "baik, apa yang kamu inginkan lagi?", Tapi dengan antisipasi penuh sukacita "dan dengan apa yang bisa kamu tolong aku hari ini?"
Saya membual tentang kata-kata salah satu wakil presiden perusahaan kami, mengatakan tentang dukungan:
“ Dukungan Teknis - mereka monster! Mereka tahu tidak hanya bagaimana menyelesaikan masalah teknis, tetapi juga bagaimana berbicara dengan pelanggan. " (Dukungan teknis adalah beberapa orang yang tidak nyata! Mereka tidak hanya tahu bagaimana menyelesaikan masalah teknis, tetapi juga tahu bagaimana melakukan dialog dengan klien dengan benar. ”)
Dan kami benar-benar dapat, apalagi, kami mengajarkan ini: seseorang dengan bahasa yang baik (terutama yang kedua atau ketiga, selain bahasa Inggris), yang tahu bagaimana berkomunikasi dengan pelanggan dan memahami mengapa ini diperlukan, kami memperkenalkan TI secara umum dan produk kami pada khususnya (apakah Anda tahu berapa banyak lulusan universitas bahasa yang berbakat bekerja untuk kami - tetapi mereka mulai dengan hampir nol pengetahuan!). Dan kami juga dapat memperketat spesialis teknis yang baik dan membantu mengembangkan soft skill
Tetapi ini adalah kisah yang sangat berbeda.
***
Bagaimana dengan Anda, pembaca yang budiman? Punya sesuatu untuk dibagikan di komentar?
Ya, jika Anda mengenali diri Anda di paragraf sebelumnya, lihat
karier.veeam.ru/departments/support , mungkin ada lowongan untuk Anda.