Tarian dengan dukungan: jenis dan bentuk dukungan. Sistem pendukung bekerja dalam pertempuran

Halo semuanya! Nama saya Alexander Afenov dan saya adalah pemimpin tim dari Tim Pemrosesan Pesanan di Lamoda. Hari ini saya ingin memberi tahu Anda tentang bagaimana kami mendapatkan dukungan.

Pertama, mari kita bicara tentang bagaimana itu tertanam dalam proses kita dan bagaimana secara umum kita merencanakan pekerjaan kita, lari cepat dan iterasi.

Maka saya akan memberi tahu Anda dari mana dukungan itu dapat berasal dan jenisnya dibagi.
Saya akan membagikan pengalaman bagaimana kita dalam tim menangani setiap jenis dukungan.

Pada akhirnya, kami mempertimbangkan pro dan kontra dari praktik yang kami gunakan dan rangkum.


Tim saya sekarang memiliki dua sistem. Yang pertama adalah hal besar dan menakutkan yang disebut Order Processing . Ini adalah sistem yang mengotomatiskan siklus hidup suatu pesanan dari proses pembuatan hingga pengiriman (atau pengembalian).

Layanan ini berputar pada PHP 7, dibungkus dengan Docker dan diatur oleh Kubernetes, tetapi pada saat yang sama diimplementasikan pada kerangka Zend1 dan potongan-potongan Symfony 2. Mereka yang memprogram pada PHP sekarang mungkin bergidik. Untuk selebihnya, saya akan menjelaskan bahwa Zend1 adalah kerangka kerja yang memiliki akhir hidup satu setengah tahun yang lalu. Itu tidak lagi didukung dan bahkan tidak memiliki patch keamanan.

Proyek ini besar (lebih dari 150 ribu baris kode), dan tidak banyak pekerjaannya. Misalnya, tidak hanya memproses pesanan, tetapi karena suatu alasan mengirim surat, sms, push, transfer data ke sistem lain. Oleh karena itu, kami memotongnya menjadi layanan microser terpisah.

Hal pertama yang kami bawa dari monolith adalah apa yang disebut alat Pengembalian Uang . Dia adalah layanan kedua yang dijalankan oleh tim saya dan bertanggung jawab untuk pengembalian uang secara otomatis kepada klien (lebih lanjut dalam laporan kolega saya) .

Terlepas dari kenyataan bahwa alat Pengembalian Dana memiliki tumpukan teknologi modern, ia masih menghasilkan banyak dukungan karena warisan pemrosesan Pesanan.

Ini terjadi karena kami mengambil proses bisnis tertentu, yang dulunya dibangun di atas banyak file excel, dan mentransfernya ke sistem baru yang bekerja melalui Kafka, dan juga berinteraksi dengan beberapa sistem. Tentu saja, ketika memperkenalkan sistem baru dan mengubah proses bisnis, kami mendapat dukungan. Dan selama bertahun-tahun bekerja dengan ini, kami telah memperoleh beberapa pengalaman.

Saya percaya bahwa orang dibagi menjadi dua kategori: mereka yang memiliki sistem produksi yang menghasilkan dukungan, dan pembohong. Karena itu, saya akan berbagi pengalaman yang dapat bermanfaat dalam mengoptimalkan proses Anda. Jika solusi yang diusulkan (dalam kombinasi atau secara terpisah) cocok untuk Anda, maka lebih banyak waktu akan muncul untuk pengembangan fungsionalitas sistem Anda, analisis jaminan teknis, dan bukan untuk bekerja dengan dukungan.

Berbicara tentang alat yang digunakan akan membutuhkan konteks, jadi pertama-tama kita akan berbicara tentang yang paling mendasar.

Proses dan peran

Bagaimana kita bekerja dengan dukungan dan tempat apa yang dibutuhkan dalam sprint kita?

Bucket proporsional adalah apa yang saya sebut ember kami .

Kami mengambil 10% dari jaminan teknis sehingga tidak stagnan dan tidak menumpuk tanpa batas.

Sekitar 20% dari sprint diambil untuk meletakkan pada beberapa risiko. Misalnya, seseorang sedang melakukan tugas, tetapi orang ini "ditabrak bus." Yang berikutnya harus memeriksa kembali konteksnya. Akibatnya, kami tidak akan masuk ke penilaian, dan semuanya akan menjadi buruk.

Selanjutnya, kami meletakkan dukungan yang direncanakan. Artinya, kita sudah tahu bahwa ada sesuatu yang salah. Ini adalah sesuatu yang tidak banyak terbakar, dan kami akan memperbaikinya.

Tetapi hal yang paling menarik adalah dukungan yang tidak direncanakan. Artinya, kami berasumsi bahwa ada sesuatu yang dapat rusak selama periode iterasi, dan kami akan menghabiskan waktu untuk perbaikan.

30% sisanya adalah proyek.

Anda mungkin memperhatikan bahwa ternyata lebih dari 100%. Ini disebabkan oleh fakta bahwa kami selalu berusaha melakukan lebih dari yang kami bisa. Terkadang kita berhasil, kadang tidak juga.

Parameter dukungan utama

Kami memberikan setiap penilaian tiket dukungan berdasarkan parameter berikut:

1. Kritikalitas untuk bisnis. Seberapa penting hal ini bagi mereka dan seberapa banyak hal ini menghancurkan proses bisnis?
2. SLA Berapa lama kita harus menyelesaikan masalah untuk menyelesaikannya?
3. Prioritas

Jika terjadi kesalahan dengan pengguna sistem kami, mereka melaporkan ini ke layanan dukungan dan mengklarifikasi bahwa suatu insiden memblokir sebagian atau seluruh proses bisnis. Dukungan segera membawa tiket baru ke sistem yang bertanggung jawab dan menempatkannya sebagai prioritas .

Kekritisan dan prioritas adalah istilah yang berbeda.

Jenis Prioritas

Blocker - sesuatu menghancurkan segalanya, menghentikan bisnis. Pesanan tidak dibuat, tidak masuk pengiriman, pembayaran tidak diterima, dan sebagainya.

Mayor adalah sesuatu yang kurang penting dan dapat diperbaiki untuk waktu yang lebih lama, karena ada solusi, jalur alternatif.

Sepele Sebagai contoh, seseorang menulis bahwa tombol kami berada dalam warna yang tidak menyenangkan dan harus dicat ulang. Ada kemungkinan besar bahwa tiket semacam itu tidak akan pernah dibuat.

Ada juga yang disebut perjanjian tingkat layanan , yang dibentuk oleh layanan dukungan bersama dengan tim dan pemilik bisnis sistem. Mereka melihat lini bisnis yang telah dipecah sebagai bagian dari keluhan tertentu. Jika, misalnya, pesanan tidak lagi dibuat (roti utama toko online), maka masalah ini akan memiliki prioritas tinggi, yang kami sebut P1. P adalah prioritas, persatuan adalah yang paling penting.

P1 adalah jenis SLA, yang berarti bahwa kita harus mengambil masalah untuk bekerja dalam waktu setengah jam dan menyelesaikannya dalam beberapa jam paling lama.

P2 adalah sesuatu yang kurang signifikan yang harus kita ambil dalam beberapa jam dan putuskan siang hari.

P3-P4 adalah sesuatu yang telah rusak dan tidak memerlukan perbaikan yang mendesak. Anda suatu hari nanti dapat melakukannya, bawa ke iterasi berikutnya.

Dan di sini kita sampai pada prioritas yang ditetapkan oleh tim. Ini bisa menjadi ahli teknis, senior, insinyur pendukung - siapa pun yang berurusan dengan masalah tersebut.

Misalkan kita saat ini memiliki 4 tugas dengan prioritas bisnis utama. Orang dari tim, karena keahliannya, menempatkan nilai numerik tertentu, yang kami sebut prioritas terinci . Berdasarkan itu, papan dukungan akan disortir di masa depan. Artinya, di bagian atas akan ada tugas prioritas tertinggi untuk bisnis, yang masih diurutkan di dalam oleh pemahaman tim tentang betapa pentingnya ini sebenarnya dan seberapa cepat Anda bisa melakukannya.

Di antara parameter utama, tampaknya salah satu yang paling penting tidak ada - deskripsi normal . Cukup sering, kami memiliki tugas dukungan mulai dari sistem Sentry, di mana kesalahan, pengecualian, dll jatuh. Seseorang melihat bahwa ada beberapa masalah kecil, dan menciptakan teka-teki di Jira. Karena sistem kami terintegrasi satu sama lain, tugas muncul di pelacak tugas, dalam uraian yang hanya ada tautan ke Sentry, dan pada judul ada teks kesalahan. Itu saja.

Bagaimana seharusnya orang yang mendapatkan tugas ini bekerja dengan ini? Tidak terlalu jelas. Jika Anda menambahkan deskripsi yang baik untuk tugas ini, itu akan sangat membantu dan menghemat waktu.

Siapa yang akan menyapu semuanya?

Dan ketika semua ini dilakukan, muncul pertanyaan: siapa yang akan menyapu tumpukan yang indah ini? Jawabannya adalah: support engineer.

Anda dapat mendengarkan secara lebih rinci tentang siapa insinyur pendukung itu dan apa yang dia lakukan dalam pembicaraan saya “Hipotek Teknis: Apa dan Siapa yang Harus Dipimpin Tim” dengan TeamLeadConf 2018.

Seorang insinyur pendukung adalah seorang pria yang mengambil dan memperbaiki tugas-tugas prioritas tertinggi dari tumpukan dukungan. Karena semuanya tersortir dengan indah, kami percaya bahwa di atas adalah yang paling penting, mendesak dan "dipanggang". Jika tidak ada tugas, maka dia bisa melakukan backlog teknis.

Apa lagi yang dia lakukan?

1. Berusaha untuk mengisolasi dan menghilangkan akar penyebab , yaitu akar penyebab dukungan. Ketika Anda secara teratur menerima tiket dari jenis yang sama secara teratur, ada baiknya mempertimbangkan mengapa hal ini terjadi. Kemungkinan besar, di suatu tempat ada masalah yang bisa dihilangkan, dan dengan demikian menghentikan aliran tugas serupa.

2. Ini menetapkan tugas untuk koreksi dan pemantauan .
Jika insinyur pendukung tidak dapat menyelesaikan masalah paling banyak dalam satu atau dua hari, maka ia membuat tugas terpisah untuk itu, yang masuk ke dalam tumpukan pembangunan. Kemudian dievaluasi oleh tim dan masuk ke iterasi sebagai dukungan yang direncanakan.

Pemantauan memainkan peran penting bagi kami. Kami menggantung pemantauan tidak hanya pada metrik yang biasa kami pantau secara berkelanjutan, tetapi juga menambahkannya untuk melokalisasi masalah yang paling lama berjalan. Menurut pendapat saya, akan lebih baik jika kita memiliki pemantauan yang tidak perlu, yang kemudian kita minum, daripada masalahnya akan terus berulang dalam bentuk tiket yang semakin banyak.

3. Mencari alasan untuk otomatisasi .
Contoh : kami mentransfer data ke sistem kami, yang mengotomatiskan pekerjaan layanan pengiriman. Kadang-kadang ternyata bahkan dengan menggunakan saluran surat mati dan penerusan, kami tidak dapat mengirimkan informasi di sana. Akibatnya, pesanan semacam itu menggantung di suatu tempat, dan mereka harus marah.

Ini adalah dukungan khas yang terjadi beberapa kali setiap minggu. Untuk mengatasi masalah ini, kami memutuskan untuk membuat halaman terpisah dengan tombol "kirim ulang daftar". Kami tidak lagi memiliki dukungan ini. Artinya, mereka pikir, otomatis, memberikannya ke layanan dukungan.

Peran seorang insinyur pendukung ditransfer setiap minggu ke orang lain - ini merupakan prasyarat. Melakukan pekerjaan seperti itu lebih lama adalah stres, penurunan motivasi, dan pembusukan, karena Anda terus memperbaiki sesuatu dan tidak membawa sesuatu yang baru ke sistem.

Keteraturan sebagai sumber rahmat

Tampak jelas, tetapi sering dilupakan pula. Agar semuanya berfungsi, perlu agar proses kami dijalankan dan diamati secara teratur.

Pemeriksaan Backlog

Di mana kita akan mendapatkan backlog dukungan yang diurutkan dengan indah jika tidak ada yang melihat di sana?

Dengan cara yang baik, Anda harus menjalankannya sebulan sekali dan menutup tugas dengan status sepele (yang kemungkinan besar tidak akan Anda dapatkan). Jujurlah dengan diri sendiri dan pelanggan. Jika tumpukan karena tugas-tugas tersebut akan tumbuh tanpa batas, maka nanti Anda harus panik untuk mencoba menutupnya. Ini tidak terlalu bagus.

Penetapan prioritas terinci

Ini adalah proses di mana kami mengevaluasi seberapa penting suatu tugas. Maka akan menjadi penyortiran yang benar, dan insinyur pendukung akan mengambil tugas yang benar dari atas.

Pertempuran untuk prioritas

Misalnya, mereka menetapkan tugas untuk Anda dan berkata: “Kawan, laporan bulanan tidak diunggah. Kita perlu memilikinya dalam seminggu, tetapi tidak berhasil. Tolong perbaiki. Prioritas P1. Anda harus memutuskan dalam 2-3 jam. "

Dan Anda bertanya: "Serius? Apa yang kalian bicarakan? Lagi pula, ada satu minggu untuk memperbaikinya. Mari turun ke P2, dan kita akan punya beberapa hari. ”

Kadang-kadang orang berpikir bahwa kita tidak akan mengambil tugas, jadi mereka menempatkan prioritas tinggi khusus. Tetapi itu terjadi dan sebaliknya. Sebagai contoh, mereka menulis kepada kami bahwa pesanan tidak dibuat dan menempatkan prioritas P2. Masalah ini jauh lebih serius, oleh karena itu perlu meningkatkan prioritas ke P1. Adalah bermanfaat untuk secara sadar melakukan tawar-menawar di kedua arah.

Pembentukan tugas baru

Sebelumnya, saya menyebutkan sistem Sentry, yang mencakup tugas-tugas yang sudah dirintis oleh pelanggan. Namun, kami sendiri mengantisipasi masalah yang muncul dan melemparkan tugas ke dalam tumpukan ini sendiri.

Pemantauan Kinerja SLA

Untuk melakukan ini, kami memiliki jadwal yang menunjukkan bahwa kami memiliki tugas, waktu yang akan segera berakhir. Tampaknya teka-teki ini masuk akal sejak awal.

Dukungan Insinyur Dukungan

Menjadi insinyur pendukung adalah proses yang agak menyedihkan, jadi seseorang harus membantu. Bagaimana kita bisa membuat hidupnya lebih mudah?

Mentransfer peran ke tim berikutnya

Kita perlu menjaga jadwal siapa yang akan melakukan ini minggu depan. Namun, momen batas memang terjadi. Misalnya, seseorang mengambil tugas pada hari Jumat dan tidak punya waktu untuk menyelesaikannya. Dia mungkin menghabiskan waktu minggu depan, tetapi lebih baik menyerahkan tugas kepada insinyur pendukung baru. Jika Anda menyeret backlog menyapu selama dua minggu, orang tersebut kemungkinan besar akan sangat terdemotivasi. Anda akan melihat ini di pertemuan pribadi berikutnya :)

Bantu temukan sumber masalahnya

Orang suka hanya mengerjakan tugas, tetapi mereka tidak fokus menemukan akar permasalahannya. Layak mengajukan pertanyaan: "Jika Anda menutup tugas, lalu mengapa masalah awalnya muncul?". Praktek ini akan membantu menemukan penyebabnya, menghilangkannya, dan mungkin menyingkirkan aliran dukungan tersebut di masa depan.

Kebutuhan akan "tampilan segar"

Jika seseorang untuk jangka waktu tertentu tidak dapat mencapai hasil yang terlihat, maka tugas ini harus ditransfer ke orang lain. Orang lain akan dapat melihat masalah dari sisi lain, yang mungkin mengarah ke solusi masalah dengan cara yang berbeda.

Tetapi pendekatan semacam itu dapat menyembunyikan beberapa aspek psikologis yang menarik. Artinya, mengambil tugas dari satu orang dan memberikannya kepada orang lain, Anda berisiko mengatakan bahwa dia lebih tahu, jadi dia akan mengatasinya. Hal-hal seperti itu paling baik disajikan dengan cara yang berbeda. Fokus pada fakta bahwa kita semua perlu menyelesaikan masalah dengan sistem, dan tidak saling membuktikan siapa di antara kita yang lebih keren.

Pengembangan alat untuk otomatisasi

Mereka yang sering mendukung insinyur memahami bahwa mereka sudah "membakar" dari melakukan tugas-tugas khas yang sama. Baru-baru ini, salah satu pengembang kami memiliki kerangka mini sendiri di Go. Dia pergi ke database yang berbeda, mengumpulkan data, mendorong sesuatu di Kafka. Dengan demikian, ia dapat mengotomatiskan tugas ini sebanyak mungkin dan membuat hidup lebih mudah bagi orang lain.

Sumber Pendukung

Ada begitu banyak dukungan yang kadang-kadang kita tidak pikirkan dari mana asalnya begitu sering?

Stabilisasi sistem dan proses baru

Jika Anda membawa sesuatu yang baru, kemungkinan besar itu akan digunakan secara tidak benar. Anda akan mengalami masalah baru untuk diri sendiri, dan jaminan simpanan Anda akan segera diisi ulang dengan tiket atau tiket.

Dukungan untuk sistem yang lebih lama

Misalnya, monolit kita. Dia tidak bisa diam, karena kita selalu menambahkan, menulis ulang, sesuatu di dalam dirinya. Tentu saja, ini mengarah pada penciptaan dukungan baru.

Kegagalan teknis

Misalnya, jaringan terputus. Anda tampaknya tidak bisa disalahkan, tetapi mereka pasti akan mendatangi Anda dan bertanya mengapa pesanan tidak dibuat. Penting untuk memperbaiki, memperbaiki, memodifikasi sesuatu. Intervensi manual akan diperlukan, dan, oleh karena itu, tiket baru di backlog disediakan.

Faktor manusia

Kami memiliki kasus ketika seseorang dapat menghasilkan pesan di RabbitMQ bahwa konsumen kami menutup telepon, dan semuanya berhenti berfungsi. Ini tidak pernah terjadi selama 7 tahun terakhir, tetapi di sini entah bagaimana berhasil :)

Faktor manusia yang menyebabkan kegagalan

Seseorang dengan kata-kata "Saya akan memperbaikinya sekarang" mengeluarkan hard drive dari server tempat penagihan berputar. Sebagai hasilnya, kami mendapatkan apa yang kami dapatkan. Ini bukan pengalaman Lmoda, tetapi kasus nyata dari latihan saya.

Jenis Dukungan

Permintaan Analisis

Ketika mereka secara teratur menanyakan status sesuatu dalam basis data, mereka meminta untuk mengunggah, mengumpulkan laporan untuk periode tertentu, dan sebagainya. Ini agak menjengkelkan, jadi Anda memiliki alasan yang bagus untuk berpikir tentang otomatisasi dan hanya menyediakan antarmuka pengguna atau mempelajari struktur perusahaan.

Sebagai contoh, saya tidak segera mengetahui bahwa sebagian besar data pesanan yang kami miliki disimpan di database Oracle dari departemen D&A, dan semuanya dapat diperoleh dari sana. Dukungan semacam itu diotomatisasi melalui antarmuka atau ditransfer ke departemen analitik.


Permintaan Perubahan Data

Situasinya berbeda dan tidak dapat diprediksi. Katakanlah klien kami akan membayar pesanannya dengan kartu. Ketika kurir tiba, dia berubah pikiran dan memutuskan untuk melakukan ini secara tunai. Atau, misalnya, di suatu tempat ada masalah otomatis yang perlu diubah dengan tangan. Kita perlu memperbaiki data ini.

Untuk melakukan ini, kami mencoba membuat pegangan API baru, membuat antarmuka, dan untuk secara maksimal menjatuhkan tugas-tugas ini dari pengembangan dan dari tim Operasi kami. Ini adalah praktik yang berbahaya, dan kami menyingkirkannya melalui antarmuka dan peningkatan API.

Perbaikan proses bisnis

Jika ada kebutuhan langsung untuk mengedit sesuatu dalam database, maka ada proses bisnis kereta. Ini bisa terjadi baik karena alasan terkait IT atau ada yang salah dalam bisnis. Baik di sana maupun di sana diperlukan penyesuaian. Dalam hal ini, Anda perlu pergi ke pelanggan bisnis dan mendiskusikan apakah itu dapat dilakukan secara berbeda, atau meminta pengembangan untuk memperbaiki proses bisnis.


Fitur X berhenti bekerja

Ini adalah jenis dukungan favorit saya, karena ini adalah yang paling dapat dimengerti. Yaitu, kami memiliki beberapa jenis masalah pada prod, tetapi itu rusak dan perlu diperbaiki. Cari tahu rilis mana yang mati dan untuk alasan apa. Perbaiki dan tutup tiketnya. Semuanya sederhana.

Tetapi ada dukungan lain - fitur X tidak berfungsi . Ini mungkin terlihat seperti hal yang sama, tetapi dikatakan dengan kata lain. Namun, ini tidak benar.

Dalam situasi ini, mereka mendatangi Anda dan mengatakan bahwa hal ini tidak berhasil. Anda menghabiskan satu atau dua hari untuk menyelesaikannya. Baru kemudian Anda menyadari bahwa ini tidak pernah berhasil di sini . Itu tidak ada di sistem Anda.

Dengan cara lain, saya menyebut jenis dukungan ini "rubah" ketika seseorang licik ingin menyelipkan permintaan fitur dengan kedok tugas dukungan. Ini adalah kisah biasa yang sangat menyakitkan. Jika Anda tidak menghentikan momen seperti itu, ternyata insinyur dukungan Anda atau Anda sendiri sedang memperkenalkan fungsionalitas baru, dan masalah sebenarnya dari tumpukan dukungan masih belum terselesaikan.

Insiden besar

Ini hanya kisah peti mati dan kebakaran gambut, ketika terjadi sesuatu yang sangat buruk dalam sistem TI sehingga proses bisnis tertentu muncul.

Studi kasus dari praktik kami: kami, karena kesalahan dalam kode dan pengujian otomatis yang tidak sempurna, mulai mengirim catatan tertentu tentang status pesanan ke layanan kurir eksternal, karena itu orang tidak dapat mengambil pesanan mereka pada titik pengambilan. Ini telah mempengaruhi ribuan pelanggan. Kami harus menerima semua pesanan kembali, membelanjakan uang untuk itu. Kami tidak bisa menjualnya, dan loyalitas pelanggan hilang. Ini adalah insiden besar yang telah merugikan bisnis.

Layak untuk bekerja dengan hal-hal seperti itu dengan cara yang istimewa, dan saya akan memberi tahu Anda bagaimana kami melakukannya.

Bagaimana cara mengetahui bahwa sesuatu sedang terjadi?

Pilihan paling umum di industri adalah belajar dari pengguna . Dia, tentu saja, adalah yang terburuk, karena itu berarti mereka sudah "memanggang". , , .

, , .

— . , . , - , , , Rabbit.

, , , . , . , , Rabbit MQ. , 16 , , .



, . , shovel-plugin, . , major .

- , , - . , , , -. , .

, 5 . , , . . , - brainstorm. , .

, , .

Lamoda , . , - , CTO. , , .

— . , , .



, 13.05 -. 13.13 , . 14.50 . - 1,5 , , . , 1,5 .

?

, , . , - . , , , .

, 16.55, , 40 . , , .

Mengapa ini terjadi?

, . , . , . , - CI/CD , . , , , , , , .

— . — . , , , – . , , , IT , .

preventive actions . , - , , , . . preventive actions. , , .

/fix versions .

. — , — .

, , Major Incident. , , , , , . , , Major Incident.

. , , , . , .

, , , , -. .

?

— . , .

Lamoda , IT. , , - - , , IT-. , 80% , , , . .

, . , , , - , IT .

Sweet spot

, , , , . , . , , , , . , .