Чи є якісь відомі антидіаграми в галузі системного адміністрування? [зачинено]


9

Я знаю декілька загальних моделей, які, здається, дедевілі майже кожен проект у певний момент його життєвого циклу:

  1. Неможливість робити відключення
  2. Сторонні компоненти блокують оновлення
  3. Неоднорідне середовище
  4. Відсутність моніторингу та оповіщення
  5. Відсутня надмірність
  6. Відсутність потужності
  7. Погане управління змінами
  8. Занадто ліберальна або жорстка політика доступу
  9. Організаційні зміни негативно розмивають право власності на інфраструктуру

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


Чи не повинні це бути вікі спільноти?
Джо

Як хочеш ....
ojblass

Це питання є поза темою згідно з чинними правилами актуальності.
HopelessN00b

Відповіді:


7

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

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


4

A. не тестує відновлення - резервна копія може бути вірною і нормальною, але як відновити?

Скільки часу потрібно, що потрібно? Ви повинні знати, що робити це в умовах стресу ...

Б. немає управління конфігурацією, немає рівномірності - просто зміна тут і там, і я думаю, я тут щось налаштував ...

Хто знає, як відтворити добре зроблений сервер, якщо всі примхи не записані і в магазині немає однакових конфігурацій? Що робити, якщо вам вдасться відновити дані, але не конфігурацію програм?

C. немає моніторингу - не маючи уявлення, як і що роблять коробки

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

D. немає надмірності у вашій cfg - що відбувається, коли XX помирає

Це означає заздалегідь планувати те, що ви хочете від свого системного адміністратора.

Для мене це найважливіше.


Амін тому. Тим більше, що B і C. D є свого роду необов'язковим - ви не завжди можете мати надмірність, оскільки це питання вартості / вигоди.
Командир Кін

Ми почали використовувати Лялечку для розв’язання B, і я не можу її досить рекомендувати. Коли ми закінчимо, ми повинні опинитися в тому місці, де ми зможемо відновити майже будь-який сервер назад, де він був за годину. Якщо у вас немає С, ви фактично сліпі. Якщо у вас немає попередження, ви не знаєте, що не працює, і без графіків ви не можете сказати, що буде в майбутньому, або побачити, що відбувається зараз.
Девід Пашлі

4

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

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


Ваш другий пункт - так правдиво. І зазвичай це поза контролем техніків. Керівництво хоче, щоб технічні працівники займалися нудною роботою щодня, а третя сторона приїжджає і виконує роботу з інтерпретації. Тоді ніхто в органі не може підтримувати t = все, що встановлено стороннім. Потім техники відходять, тому що вони просто стали прославленими хлопцями служби технічної допомоги. Менеджери не можуть жити з ними, не платять без них. : /
Джейсон Тан

2

1) надмірно перспективні та недостатні (тобто підтримуючи реалістичні очікування користувачів)

2) Не перевіряють резервні копії, поки вони не знадобляться.

редагувати: я задумав номер 2 включати відновлення файлів / даних


Я маю звичку не намагатися нічого обіцяти :)
Девід Пашлі

Не обіцяючи жодного жодного знаку, змусять користувачів з розуму, управління також. Дізнатися, що обіцяти, і як відновити очікування, якщо обставини зміниться, безцінне.
Chris S

0

Не моніторинг моделей використання облікових записів AD, наприклад, час останнього входу> 30 днів

(Ми повинні це зробити з аудиторських причин, але результати є досить шокуючими)


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

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

  • Незрозуміла документація. Кожен може вирішити проблему середнього пріоритету протягом дня з усім ІТ-відділом, з яким можна поговорити. Інша справа - вирішити проблему з першочерговим завданням пізно вночі, коли ви майже самотні і не маєте поняття, чому система налаштована так, як вона є, і чому вона не відповідає тому, що йдеться в документації.

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

  • Не купувати підтримку постачальників для ключових систем, оскільки це "занадто дорого".

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

  • Невідповідні рішення - ІТ дуже легко застряг у думці "виправити це, ІТ-система повинна працювати так, як це було раніше", коли може бути більш доречним угода про менеджмент-ІТ "спробувати для 2" годин, якщо це не зафіксовано, тоді зупиніться, навіть якщо це виглядає перспективно, і перейдіть до відновлення після резервної копії ".

  • Копії тестових файлів скрізь. Ви не хочете відкривати папку, в якій працює бізнес-система чи веб-сайт, і бачити "веб-сайт / новий /, поточний веб-сайт /, копія веб-сайту /, тестування веб-сайтів /, веб-сайт-тест-Дейв /, веб-сайт-використання- this-one /, website-from-feb / і т. д.) Розробник, виробництво та тестування повинні існувати, і їх слід розділяти з кожним залученим відділом (ІТ, розробник, управління проектами тощо), знаючи, що має бути де, і домовлятися про те, як зміни Також для файлів конфігурацій.

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.