Безаварійна експлуатація обладнання. Особистий досвід

Ось вже 12 років я займаюся обслуговуванням ІТ-систем на промислових підприємствах. Дуже часто роботодавці ставлять переді мною вельми цікаву задачу: зробити так, щоб ІТ-системи працювали без збоїв і з мінімально можливим операційним бюджетом.

Для реалізації цієї мети я використовую «деформовану» ITIL. Почалося все зі зміни термінології. Справа в тому, що заводами керують люди старого гарту. Вони погано розуміють значення «Problem Management». Але дуже добре знають, що таке «усунення аварій». Тому розповідати про «проактивному управлінні проблемами» все одно, що об стінку головою битися. Оплачувати цю заморську дивину вони не хочуть.

А от коли говориш про «безаварійної експлуатації обладнання» починають слухати дуже уважно. Адже аварії — це простої обладнання, зірвані терміни поставок. Це нерви, це гроші. Керівництво заводів не хоче аварій. Тому готове вкладати ресурси в експлуатацію без аварій.

Але зміною термінології ITIL справа не обмежувалася, зміни зачіпають і процесну модель. Погано це чи добре — прочитайте статтю до кінця і вирішуйте самі.

У спрощеному вигляді безаварійну модель експлуатації ІТ-обладнання можна розділити на два процесу.

image

Зелена гілка — усічена версія процесу «Управління инциндентами». Його мета — забезпечити щоденне функціонування ІТ-систем. Це «обслуговування за фактом», т. до. ми приступаємо до роботи тільки після отримання інформації про подію інцидент.

  1. Якщо у користувача виникає потреба в допомозі ІТ-фахівців, він відправляє заявку на обслуговування в ServiceDesk.
  2. ІТ-фахівці приймають звернення в роботу, класифікують, аналізують його і приступають до виконання.
  3. Після виконання заявки вносять в ServiceDesk інформацію про виконану роботу і використаних ТМЦ (необхідно для планування закупівель на наступний період).
Червона гілка — планове технічне обслуговування (ТО). Завдання цього блоку заходів — підтримувати справний стан обладнання і комунікацій протягом усього терміну служби. Щоб не допустити виникнення інцидентів ми за заздалегідь складеним планом ліквідуємо причини їх появи.

  1. В кінці року керівник ІТ-служби складають графіки на наступний рік. При цьому використовуються документи: перелік робіт технічного обслуговування, керівництво по експлуатації, плани післяаварійного відновлення.
  2. протягом року (згідно зі складеним розкладом) через ServiceDesk видаються завдання на конкретну роботу по обслуговуванню обладнання.
  3. Співробітник ІТ-служби виконує визначений регламентом перелік робіт. Якщо виявляє відхилення від нормального функціонування системи — створює заявку в ServiceDesk.
  4. Після завершення робіт заносить інформацію в ServiceDesk інформацію про виконану роботу і використаних ТМЦ.
За моїми оцінками, грамотно спланований і правильно реалізоване дозволяє на 50-70% знизити кількість звернень користувачів за підтримкою. І оскільки планування технічного обслуговування зроблено зовсім не по ITIL, варто розглянути цю процедуру більш докладно.

По-перше, хочу зазначити, що в моєму розумінні складається з кількох видів робіт:

  • Планово-попереджувальні роботи. Проводяться строго за графіком, без прив'язки до фактичного стану устаткування. Дозволяють точно планувати запаси комплектуючих частин ізвести до мінімуму відмови обладнання. Можуть здійснюватися персоналом середньої кваліфікації, але вимагають значних фінансових витрат (т. к. міняємо ще робоче деталі, тримаємо значний запас комплектухи на складі).
  • Планово-профілактичні роботи. Ініціюються з урахуванням поточного стану обладнання, тому вимагають високої кваліфікації обслуговуючого персоналу і вкладень в інструменти діагностики. Але дозволяють мінімізувати витрати на комплектуючі матеріали.
  • Нормативне обслуговування. Виконуються у відповідності з вимогою наглядових органів і нормативних документів (ПТЭЭП тощо). ІТ-служба рідко стикається з такими роботами, тому загострювати увагу на них не будемо.
  • Поточний ремонт. Проводиться раз на кілька років з метою подовжити нормативний термін служби устаткування і комунікацій.
Невеликий відступ. Пам'ятаєте, з опису якої мети я почав цю статтю? Зробити так, щоб ІТ-обладнання працювало без збоїв і з мінімальним операційним бюджетом.

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


По-друге, хочу зазначити, щоб персонал ІТ-служби зміг якісно провести технічне обслуговування, він повинен бути забезпечений документацією на проведення ТО.

Фундаментом для організації єперелік робіт по кожній групі устаткування. В якості прикладу наводжу фрагмент нашого переліку робіт з обслуговування ПК.

  • Опитування користувача про недоліки в роботі обладнання.
  • Перевірка цілісності наклейок з інвентарним номером і номером ліцензії.
  • Огляд електричних кабелів підключеного обладнання.
  • Перевірка S. M. A. R. T. HDD, при необхідності тестування HDD.
  • Огляд компонентів системного блоку (материнська плата, блок живлення, з'єднувальні кабелі і т. д.).
  • Видалення пилу і бруду з поверхонь обладнання і всередині системного блоку.
  • Заміна HDD, RAM, клавіатури, миші та інших вузлів (у разі вироблення ресурсу).
  • Контроль температури в приміщенні.
  • Фіксація виконаних робіт в ServiceDesk.
Тобто це простий «чекліст» для обслуговуючого персоналу. Склавши такий перелік можна переходити до формування графіка устаткування. Але що б проводяться роботи були обґрунтованими і максимально ефективними, варто підготувати ще кілька документів:

image

Керівництва по експлуатації основних ІТ-систем (ЛВС, облікова система тощо). У таких документах має містити загальний опис ІТ-систем, опис дій персоналу в штатному режимі роботи, визначення зон відповідальності та обов'язків команд експлуатації.

Плани післяаварійного відновлення (DRP). У цих документах повинні бути описані найбільш ймовірні збої в роботі ІТ-систем і покрокові процедури відновлення працездатності. Крім цього повинні бути описані програми тестування планів.

З цих документів в графік робіт «перекочують» дії обслуговуючого персоналу в штатному режимі (в основному це перевірка log-файлів) і процедури тестування DRP (заміна жорсткого диска на сервері з метою перевірки роботи RAID і т. д.).

Третій момент, на який хочу загострити вашу увагу. Щоб графіки ТО найбільш точно відповідали потребам бізнесу в відмовостійкості обладнання, потрібно враховувати кілька факторів: плановий термін служби комплектуючих, рекомендації виробника обладнання з проведення ТО, фактичні умови експлуатації. Що це означає на практиці? Зокрема те, що для груп устаткування, що знаходиться в різних умовах експлуатації, варто зробити різні графіки обслуговування.

Наприклад ми розробляємо окремі графіки обслуговування ПК в офісних і виробничих приміщеннях. Комп'ютери в офісі розміщені на столах або підлогових підставках, вологе прибирання приміщень здійснюється щодня. У виробничих приміщеннях хоч і роблять вологе прибирання кожен день, все одно дуже пильно. Тому ТО в офісі проводимо 2 рази в рік. Перший раз у травні, другий раз в листопаді. А ось у виробничих приміщеннях ТО проводиться щомісяця. Перелік робіт я вказував вище.

На цьому я б хотів поки зупинитися і дізнатися думку шановного співтовариства.
чи Варто описувати модель «безаварійного обслуговування» далі?

/>
/>


<input type=«radio» id=«vv66239»
class=«radio js-field-data»
name=«variant[]»
value=«66239» />
Так
<input type=«radio» id=«vv66241»
class=«radio js-field-data»
name=«variant[]»
value=«66241» />
Немає

Проголосувало 13 осіб. Утрималося-3 людини.


Які моменти потрібно розкрити більш детально?

/>
/>

<input type=«checkbox» id=«vv66243»
class=«checkbox js-field-data»
name=«variant[]»
value=«66243» />
Інтеграцію «безаварійного обслуговування» з ITIL.
<input type=«checkbox» id=«vv66245»
class=«checkbox js-field-data»
name=«variant[]»
value=«66245» />
Планування закупівель для профілактичних і регламентних робіт.
<input type=«checkbox» id=«vv66247»
class=«checkbox js-field-data»
name=«variant[]»
value=«66247» />
Труднощі, що виникають при впровадженні цієї моделі у практику роботи ІТ-служби.
<input type=«checkbox» id=«vv66249»
class=«checkbox js-field-data»
name=«variant[]»
value=«66249» />
свій варіант (вкажіть пжл в коментарях).

Проголосувало 13 осіб. Утримався 1 людина.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


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

0 коментарів

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