Тест Joel для завдань системного адміністратора

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

Які 12 питань системні адміністратори повинні задати на співбесіді, щоб допомогти їм вирішити, чи це хороше місце для роботи?

Дотримуючись правил Джоеля:

1. Питання повинні бути платформними та техногенними
2. Питання повинні викликати просту відповідь, наприклад, так чи ні

РЕДАКТУВАННЯ. Будь ласка, опублікуйте одне запитання, щоб ми могли бачити, за що голосують користувачі.

Ви використовуєте систему відстеження інцидентів / квитків?

Ви виконуєте резервні копії системи та регулярно відновлюєте тест?

• Скільки інших людей працюватимуть поряд з собою в щоденних операціях?

Це впливає на вашу здатність виступати дуже прямо. Це також впливає на вашу здатність приймати безперебійну відпустку ...

• Хто перший відповів на проблеми?

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

"Тільки ти" - не прийнятна відповідь. Це повна відсутність організації, і слід супроводжуватись питанням "Як відстежувати запити від користувачів?". На це треба відповісти чимось, окрім як «ти цього не робиш».

• Яке співвідношення існуючих систем до адміністраторів?

Це не повинно бути занадто високим (вище 50: 1) або занадто низьким (нижче 5: 1). Занадто висока і ваша навантаження буде настільки серйозною, що ви будете топтати воду, щоб залишатися на плаву. Занадто низький рівень, і ви або магазин для одноосібників, або виникають серйозні проблеми зі здатністю магазину керувати системами.

Як завжди, є винятки з правила; випадки, коли 200+ систем можна зображувати з одного джерела (думайте, веб-заголовки), і випадки, коли бізнес дуже малий (20 працівникам може знадобитися лише 2 сервери).

• Яке співвідношення кінцевих споживачів / клієнтів до адміністраторів?

Це міра очікування. Це ваші "клієнти". Коли виникнуть проблеми, це буде величина "тиску", на який ви будете вирішувати ситуацію. Організація 5000 із лише двома адміністраторами може стати дуже, дуже напруженим місцем, якщо у ваших систем є проблеми.

• Яке співвідношення кінцевих споживачів / клієнтів до існуючих систем?

Це міра завантаженості сервера. Дуже високі співвідношення можуть бути ознакою надмірного використання або бюджетних обмежень, які зв’яжуть ваші руки, коли прийде час розширюватися. Недостатнє використання також може бути проблемою, коли його не вимагають (тобто має сенс, що HR має власний сервер, але файловий сервер лише для 5 "постійних" користувачів в організації з 5000 є червоним прапором); це може зажадати певної "віртуалізації" для консолідації серверів ...

• Чи існує процес обробки оновлень існуючих систем, наприклад, застосування патчів постачальників або оновлення мікропрограмного забезпечення?

Це має бути будь-яка інша відповідь, окрім (а) "я не знаю" або (б) "ми не оновлюємо".

• Скажімо, сервер загоряється. У разі виникнення кризи чи лиха, який термін прийнятний як час простою?

Це завжди має бути розумним питанням. Якщо інтерв'юер зіпсується з цього питання, вони не розуміють природу вашої роботи, життєво важливу підказку щодо майбутніх перспектив. Якщо очікування роботи працює цілодобово, це добре - якщо у них немає інфраструктури для цього, це означає, що ви будете багато працювати на нянях . Знання того, що є, а що не прийнятно, допомагає підказати свої картки вам про їхні справжні очікування.

• Якщо говорити про пожежу, чи є у вас система пожежогасіння для вашого обладнання, і чи вона відповідного типу?

Водні дощувачі - не прийнятна відповідь. Це дійсно станеться, і ви будете отримувати організації , які думають , начинка стійки в комору без вентиляції і накладні витрати пожежогасіння є прекрасною ідеєю . Якщо це занижено, ігнорується або зустрічається з ворожістю, вставайте, дякуйте інтерв'юеру і не ходіть, бігайте ...

• Опишіть процес резервного копіювання даних та формат використовуваного сховища.

Це ще одне питання, на яке слід відповісти, окрім "ми не маємо" та "у нас немає резервних носіїв інформації".

• Ви регулярно тестуєте свої резервні копії та як часто?

Подальші дії щодо вищезазначеного питання. Якщо ви не регулярно тестуєтесь, ви просто запрошуєте неприємності.

• Чи відомий бюджет і процес придбання як витрат на капітал, так і незначних закупівель? Чи можете ви пояснити мені процес, який я б використав, щоб придбати щось?

Якщо відповідь «ми (хтось інший) будемо купувати її так, як нам потрібно», це червоний прапор. Це означає, що "ми не довіряємо вам купувати обладнання, коли воно вам справді потрібне, тому ми будемо замість цього робити хтось інший". Завжди має бути якийсь бюджет.

Процес придбання чогось повинен бути досить простим, щоб пояснити менше ніж за 2 хвилини. Він не повинен включати більше двох сторін, що підписуються (більші цифри вказують на бюрократичну стрічку), і поворот повинен вимірюватися днями та годинами, а не тижнями (критичні закупівлі будуть проводитись, якщо вони занадто довгі). Завжди має бути якийсь процес.

• Чи є у вас план оновлення та переробки старого обладнання та як часто це відбувається?

Я насправді бачив компанії, що працюють на 18-річних міні-комп’ютерах, яких підтримують договори про підтримку та багато запчастин від постачальника підтримки. Звичайно, оригінальний виробник обладнання вже давно відійшов ...

Настільні пристрої ніколи не повинні оновлюватися швидше, ніж 3 роки, або повільніше, ніж 5. У компаніях з обмеженим бюджетом розтягнення робочого столу на 5 років іноді є відповідним рішенням.

Біт у переробці - це тест на перевірку наявності у них "одноразового" ставлення до старого обладнання. Це погано в тому сенсі, що ви повинні належним чином утилізувати його через відомий переробник, але добре в тому сенсі, що ви можете натиснути на старе обладнання в тимчасовий обов'язок, якщо виникне потреба. Це також дасть вам відчути розмір їх "боніарду" (купу старого обладнання, яке зберігається навколо).

Пов’язані запитання:

https://serverfault.com/questions/44638/how-often-does-tech-refresh-happen

Чи є у вас план відновлення після аварій і чи включає це ІТ?

Результати чудових коментарів: Якщо так, то чи включає вона всю організацію, а не лише ІТ? Чи включає він персонал і чи регулярно ви тестуєте його?

Пов’язані запитання:

Кращі практики та ресурси щодо розробки плану відновлення стихійних лих?

Чи задокументовано поточне середовище?

Чи документовані та послідовні як політики, так і процедури?

Чи оцінюють внутрішні облікові практики цінність послуг, які ІТ надає іншим підрозділам, чи ІТ просто обліковується як центр витрат?

(Це майже той самий питання, що і "Стік" - це пріоритет у вашій організації чи це необхідне зло? ", Але сформульовано так, щоб можливо викликати чесну відповідь замість кричущо телеграфуваної правильної брехні.)

Одне, що я вважаю обов'язковим - це тестувальна машина, яка має однакові технічні характеристики обладнання, як і живий сервер.

"Наскільки тісно ваші середовища тестування відповідають виробництву?"

Мені здається дуже цікавим, що багато відповідей сформульовано "У вас це є?" або "Ви це робите регулярно?" Якщо я буду прийнятий на роботу в якості нового систематичного адміністратора, я би сподівався, що зможу реалізувати ці речі, якщо їх уже не було. Журнали відновлення та ліквідації наслідків стихійних лих - це не те, що могло б зробити або порушити інтерв'ю. Якщо вони цього не робили, вони будуть після того, як мене прийняли на роботу.

Моє головне питання, як я вже згадував, - це підтримка згори. Якщо я скажу, що нам потрібно замінити сервери, я хотів би отримати користь від сумнівів. Або якщо я впроваджую набридливу політику безпеки, я не хочу, щоб партнери надавали імунітет людям, які скаржаться, щоб вони могли виглядати як приємні турботливі начальники.

Системний адміністратор знаходиться в дивному місці в ієрархії корпоративної структури. Іноді вони керуються і встановлюють свої пріоритети, виходячи з потреб самого персоналу початкового рівня, а іноді диктують політику управління. Ми знаходимося в самому дні і в самій вершині ланцюга одночасно.

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

Чи проводяться всі нові придбання системи / програмного забезпечення / додатків через ІТ і чи має ІТ можливість відхиляти та пропонувати іншу систему, можливо, ту, яка вже використовується в іншому відділі?

Чи готові ви витратити гроші на належні засоби моніторингу / реєстрації?

-і, з оригінального питання про тест Джоеля:

Чи використовуєте ви найкращі інструменти, які можна купити за гроші?

Пов’язані запитання:

Програмне забезпечення для моніторингу здоров'я серверів

Чи можу я поговорити з вашим попереднім систематиком?

Ви входите в систему, використовуючи загальний обліковий запис адміністратора / root?

Завжди весело кидати відповідь "ні" посеред кучки "дріжджів".

Чи є у ІТ свій бюджет?

Моїх немає, і ми покладаємось на кошти інших відомств на все, що нам потрібно. Відстій великий час.

Чи зберігаєте ви копію своїх резервних копій поза сайтом?

Чи можу я мати допомогу продовжувати навчання та освіту, і чи дозволите ви мені купувати матеріали, щоб бути в курсі питань безпеки?

Чи підтримаєте ви мої рішення співробітників щодо політики та процедур, незалежно від того, наскільки непопулярними?

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

• У вас є контроль зміни конфігурації?
• Чи є у вас політики відновлення даних?
• Ви виконуєте щоденні резервні копії?
• Чи є у вас база даних проблем?

Оновлення

• У вас є вбудована надмірність?
• Чи є у вас найкращі гроші на апаратне забезпечення, які можна придбати?
• Чи можете ви налаштувати новий ноутбук або робочий стіл за один крок?
• Чи регулярно існує політика щодо виправлення патчів?

ІТ-пріоритет у вашій організації чи це необхідне зло?

Де кавоварка?

Чи використовуєте ви контроль версій? Що ви ставите під контроль версій?

Чи можуть ваші системні адміністратори писати код?

Чи є у вас централізований журнал? Хтось їх читає?

Чи існують політики / пороги часу відповіді для критичних систем? (або який кращий спосіб сказати: "Ви вже знайомі з концепцією того, що слід, а що не повинно мене вставати з ліжка о 3 ранку?")

Чи можете ви додати нових користувачів в один крок?

Повагу: Чи можете ви зробити збірку за один крок?

Я єдиний системний адміністратор? Це може бути єдиним системним адміністратором - насправді це може бути весело, але тільки якщо бізнес розуміє наслідки, які приводять нас до:

У вас є угоди SLA ?

Запитайте їх, якщо вони, кажуть, системному адміністратору, чи означають вони насправді SA і DBA та Net Admin і Apache / IIS Admin та Email Admin та AD Admin та усунення несправностей на робочому столі.

Чи використовуєте ви систему управління конфігурацією, наприклад Ляльковий або шеф-кухар?

Чи можете ви сказати, які патчі відсутні для яких систем у будь-який момент?

Чи використовуєте ви управління патчем / змінами?

Ви проводите щомісячний / щорічний тест на відновлення після аварій?

Чи підзвітний ІТ та вимірюється системою часу роботи та квитків?

Чи використовуєте ви централізоване управління квитками для всіх відділів ІТ?

Чи можуть працівники перервати ІТ-персонал за столом?

Чи мають ваш ІТ-персонал внесок у створення рішення для бізнес-сфери чи вони просто слідують вказівкам вищого керівництва?

Чи зберігаєте ви критичні апаратні та програмні платформи ліцензовані та підтримувані, навіть коли ви наближаєтесь до закінчення терміну служби?