Нашої техпідтримці не приходиться тужить чи не всі «негідники» однакові



Техпідтримка. Це, реально, — «хлопці героїчної професії». Вони першими приймають на себе атаки неспокійних юзерів, виступають в ролях «докторів Хаусів», переговірників і більше інших в ІТ можуть розповісти про типових та унікальних «клінічних випадках»… Чому я пишу саме в таких формулюваннях? Напевно, тому, що знає, освічений, досвідчений клієнт економить свій час, пам'ятає за що платить і не вимагає неможливого.

Цей пост з'явився після мого спілкування з TeamLead нашої технічної підтримки. Під катом кілька думок про те, який найчастіше бачать техпідтримку хостера клієнти, і спроба відповісти на питання: чи може техпідтримка бути не реактивною, а проактивного? Ми пройдемося по 3 розхожим тез-міфам, які забезпечимо прикладами з нашої роботи – приватними випадками та збиральними образами.

«Будь продавець намагається мене на обдурити...»

Це упередження формувався десятиліттями. Радянська торгівля, перші кроки капіталізму. Установка «нас скрізь обважують і обманюють» має глибокі історичні корені. Звідси, як наслідок, — стереотип: «Яка вигода хостеру тримати тебе на низькому тарифі? Ясна річ, йому хочеться якось тебе стимулювати, щоб ти більше платив!»

Життєва ситуація: хостер бачить, що клієнт «виріс» і за своїми показниками уперся в стелю — «закінчилася» пам'ять/потужність процесора/місце на диску. Хостер, природно, сповіщає клієнта про це, пропонуючи додати ресурсів. У відповідь від клієнта прилітає: ні, я знаю, що можна оптимізуватися, йому кажуть – оптимізуються. Клієнт (без удаваної скромності і сорому): эээээ...., так може в рамках безкоштовної підтримки? ..., ну будь ласка, ну зробіть і т. д. (Про «безкоштовну» підтримки нижче).

Очевидно, що є межі розумного і хостер не може оптимізувати інфраструктуру клієнта. Це, я б сказав, процес інтимний — винятковий і гранично особистий питання системного адміністратора на стороні клієнта. При нестачі ресурсів у клієнта є 2 можливості: погодиться на збільшення потужності або звернеться до веб-розробників, які можуть покопатися в його, припустимо, сайті і з'ясувати, що не так створюється багато непотрібних темп-файлів або є можливість створювати менше кеш-файлів. Або перевірять скрипти і плагіни сайту, оптимізують їх роботу, а то й повністю відключать – це комплекс дій дозволяє використовувати менший обсяг оперативки. Але є «особлива» категорія клієнтів. Навіть у ситуації, коли порядок в інфраструктурі може і повинен бути наведений власними силами, вони намагаються навантажити хостера.

Наприклад, жив-був клієнт, у якого був сервер. Одного разу цей сервер почав зависати. Клієнт захвилювався, почав писати в ТП. Наші адміни знайшли помилку – вони виникла через недавнього оновлення З сайту. Для виправлення потрібно було поміняти рівне 1 слово в конфігурації і клієнтові про це написали, навіть дали посилання на роз'яснення з офіційного сайту. Здавалося б… Але клієнт, такий, поміняйте ви... З одного боку — начебто дрібниця на кілька хвилин, з іншого — всі ці «дрібниці», коли вони йдуть потоком, ну просто нереально відволікають сисадміна. І почув клієнт логічний та обґрунтовану відповідь, сповнений всілякої ввічливості.

Не завжди дорожче – краще для клієнта
Поговоривши про, хм..., «скромності і дбайливості», подивимося на інший полюс. Бувають випадки, коли клієнт рішуче налаштований влаштувати атракціон небаченої щедрості — хоче купити щось дорожче, навіть якщо це зовсім не потрібно. Спокуса велика, але ми всіляко намагаємося спрямувати клієнта «на шлях істинний» і радимо вибрати саме те, що вирішить проблему. Був, наприклад, такий випадок: клієнт вирішив переїхати з одного нашого ЦОДа у другій (він подорожче). Озвучив причину — там, мовляв, є захист від DDoS і він її хоче-мріє. Що ж, якщо ти бачиш проблему і знаєш, як її вирішити, то… Однак проблема, як виявилося, була не в тому, що його-де дедосят. Проблема була в гальмуванні сайту, а природа гальмування — в його некоректних налаштуваннях. Клієнту так і доповіли: мовляв, так, можемо перевести вас, але це не дасть ніякого результату, апаратна захист від DDoS у вас не спрацює, ваш сайт також буде гальмувати, вам потрібно перенастроювати сайт… У цієї історії щасливий кінець.

«Я плачу хостеру гроші – він повинен мені все налаштувати!»

Невеликий відступ про «безкоштовну» техпідтримку, так як зустрічається чимало прихильників думки про те, що хостер крім «тарифів подорожче», завжди хоче впарити» ще й платну техпідтримку.

Дорослі люди розуміють, що зовсім нічого безкоштовного не буває – робочий час адміністратор завжди кимось оплачується. Така безкоштовність – швидше, наслідок лояльності до клієнта. Але вона не може бути безкінечною. Ми говоримо про базову підтримку, як про деякому обсязі сервісних послуг і часу, які за замовчуванням включені в основну послугу. У базову підтримку не входять специфічна налаштування або моніторинг критичних сервісів клієнта. За бажанням клієнт може придбати пакет адміністрування, що передбачає моніторинг його роботи, що розміщена у нас, інфраструктури. Для моніторингу існує ряд маркерів, за яким ми відстежуємо стан ресурсів клієнта та які сигналізують про необхідність прийняття рішень. Приклад такого маркера – «залишилося менше 20% диска».



Але я б не писав про базову техпідтримці якщо б все було чинно і благородно. Наступна історія сталася з одному дуже хитро… мудрим клієнтом. Одного разу він вирішив обіграти хостера в «інтелектуальному поєдинку». Говорить якось клієнт нашої ТП – все знаю-розумію і заздалегідь каюсь, це виходить за рамки базової техпідтримки, але налаштуйте мені Apache, щоб сайт відкривався. Ну, це 5 хвилин справи – налаштували. На наступний день стукає той же хитро… мудрий клієнт знову: а налаштуйте мені будь ласка, MySQL? Ну знову, начебто, роботи не багато– налаштували. Але це не кінець історії. Що було далі? Переграв хитрун хостера. Потроху, потроху, з витриманими паузами, 1 раз в 2-3 дні, свою велику проблему клієнт дробив на дрібні, намагаючись її вирішувати руками нашої техпідтримки. Коли ж ми підрахували, скільки зроблено для цього клієнта за місяць – виявилося, що хитрож… мудрому клієнту ми розгорнули майже всю інфраструктуру:-)

Як читач, можливо, здогадався, з цієї історії добрі молодці винесли важливий урок на майбутнє.

Бажання клієнта далеко не завжди – «закон»
Природно, ми оцінюємо запити клієнтів, навіть якщо це очевидно виходить за рамки обов'язків базової техпідтримки хостера. Основний критерій оцінки – час роботи системного адміністратора. Клієнт: взяв VDS, каже – поставте мені Ubuntu – не питання, поставили, — поставте, каже мені ще LAMP. Ну якщо клієнт просить – гаразд. А клієнт розхрабрився, береги з виду втратив: а тепер, говорить, розгорніть мені сайт, налаштуйте БД і оптимізуйте Apache. А це, шановний, процес досить тривалий і тому виходить за рамки базової техпідтримки. Для такої підтримки адміністратору потрібно добре вивчити вихідні дані інфраструктури замовника, код сайту, на яку кількість користувачів це розраховано і так далі – це велика робота, до 6 годин роботи системного адміністратора. Ясно, що адміністратор не може займатися цим по доброті душевній. Є маса клієнтів і хто з них оплатив ТП понад базової. Мораль історії: не всяке бажання здійснимо.

«У кожній незрозумілої ситуації – звертайся до хостеру!»

З нашого досвіду найбільше запитів на підтримку (близько 80%) створюють так звані «типові користувачі». Вони завантажили шаблон сайту, взяли доменне ім'я, купили хостинг, підключили багато плагінів, і все – продакшн. При виникненні будь-якої проблеми, пов'язаної або не пов'язаної з хостингом – клієнт все одно звертається до ТП. Просто у свідомості «типового користувача» найчастіше загоряється лампочка «по всім питанням треба звертатися до спеціально навченої людини»: — а куди ж писати? В техпідтримку движка, який використовується на сайті? Найчастіше він безкоштовний. Знайомого сисадміна для особистого користування у нього, нерідко, немає. Часто немає і звички спочатку пошукати рішення своєї проблеми десь в інеті, на форумах. Непросто це. А тут же ж, ялинки, є хостер «я ж їм гроші плачу, вони там саме зараз сумують – а тут такий я з питанням «унікальним і за профілем»!»

Один клієнт увесь час скаржився на зависання сервера. Коли адмін заходив сервер – вже все працювало — клієнт встигав перезавантажити свій сервер. Його неодноразово просили сервак не перезавантажувати, бо помилку потрібно було відстежити. Історія не донесла до нас був клієнт нелюдем або просто «без царя в голові», відомо лише, що він нікого не слухав і весь час перезавантажується. Довго чи коротко — моніторинг показав, що є звернення до файлів на сайті, до сторінок сайту, немає недоліку в потужності: на сайті працює. Виявилося, причина в поганій зв'язку — в тому місці де клієнт відкриває сайт. У нього поганий канал зв'язку – сайт довго вантажиться, і він думає, що проблема з сервером.

А була ще інша історія… Клієнт скаржився на зависання сайту. На думку шановного всі його проблеми перебували на стороні хостера. Впевненість клієнта була ну просто фундаментальною. Продіагностували. Виявилося — закінчується оперативка, система вбиває процеси щоб звільнити пам'ять і зупиняє MySQL, NGINX. Клієнту про це сказали, він повозмущался, мовляв, я говорив — у вас щось не так. Мовляв, все було добре, «раніше, от, ніколи нічого не закінчувалося», а тепер раптом почало кінчатися. Йому задали 1 питання – у вас збільшилася кількість відвідувань? – так, з гордістю відповів клієнт і аж зашарівся від задоволення. Хотілося б написати, що під уважним поглядом співробітника ТП до нього досить швидко дійшло очевидне. Але спілкування йшло по проводах і в листуванні і очей його адміни не бачили. Проте все стало на свої місця.



Як вже говорилося, більшість запитів в техпідтримку це — «типові запити від типових користувачів». Бувають випадки, коли клієнт просить, але розуміють, що їх прохання, м'яко кажучи, не за адресою і тому просить посилання на «почитати як вирішити мою проблему» – тобто тикніть пальцем, не можу знайти. Нерідка ситуація і для спрощення життя клієнтами і ми собі створили, і наповнюємо вікі — www.sim-networks.com/wiki.

Рядові користувачі не дають техпідтримці нудьгувати, а є випадки, коли «запалювати» починають сисадміни клієнтів. Ось приклад, хотів клієнт налаштувати віртуальну машину від свого маршрутизатора до маршрутизатора у нашому дата-центрі. Йому повідомили що і як налаштовувати, він спробував. Потім клієнт попросив інструкцію по налаштуванню, наш адміністратор написав інструкцію. Клієнт 2 дні мовчав, потім каже: у мене не виходить — половина адрес доступні в підмережі клієнта, а половина – ні. Почали розбиратися – виявилося, що у клієнта варто маршрутизатор, який підключені частина клієнтів, далі в цей же маршрутизатор підключений сервер з pfSense – і вже в нього підключена друга частина клієнтів – тобто у нього 2 файрвола – але системний адміністратор якось забув про це згадати:-)

Буває, і спамери трапляються...
У разі якщо клієнти розсилають спам, завжди стоїть питання блокування. Найчастіше наша техпідтримка запитує в клієнта – що сталося? Ми не рубаємо з плеча, в таких ситуаціях потрібно враховувати все. По-перше, історію клієнта: якщо клієнт ніколи нічим таким не займався, то з чого б це раптом він «зробився» спамером? Виявилося, що клієнта просто зламали, тому ми його сповістили, допомогли йому поміняти паролі і очистили чергу. Хоча нерідко хостери не заморочуються розглядами з цим – просто блокують і все.

Звичайно, є випадки, коли клієнт блокується при спам-розсилку. При аларме від Spamhaus, наприклад, ми обов'язково повідомляємо клієнта про блокування. Але якщо клієнт говорить, що його зламали, просить подивитися і розібратися, ми це все робимо швидко і безкоштовно.

Від спамерів непросто себе захистити. Буває трапляються і махрові майстри цієї справи. Вони, як правило, беруть найдешевшу VDS, 15 IP-адрес, і як тільки на нього приходять скарги, – ми його одразу блокуємо. Хоча, трапляється, спамер прикидається «білої овечкою». Зараз їх тиснуть звідусіль, і вони намагаються змінити свій підхід – не беруть найдешевші VDS, переходячи на більш дорогі, і працюють поки не заблокують. А коли їх блокують навіть не відповідають на листи і не пишуть в техпідтримку, розуміють, що їх розкрили і просто йдуть.

Такі справи…

Повертаючись до питання на початку статті:

чи Може техпідтримка бути проактивним, а не реактивної?

У цій статті ми розповіли про те, як ми вирішуємо нелегкий питання балансу між клієнт-орієнтованістю і періодично виникають «чиїмось» бажанням повісити на хостера «всіх собак». Для нас проактивність техпідтримки полягає в гнучкості, незашорености, не зацикленості на догмах. Ми переконані, що техпідтримка повинна відштовхуватися від ситуації клієнта, а вони завжди різні. Тому ремонт – не роботи, а живі люди, такі ж, як і наші клієнти.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.