Я системний адміністратор FirstVDS, і це — текст першої вступної лекції з мого короткого курсу допомоги колегам-початківцям. Фахівці, які нещодавно почали займатися системним адмініструванням, стикаються з низкою тих самих проблем. Щоб запропонувати рішення, я взявся написати цей цикл лекцій. Деякі речі в ньому специфічні для технічної підтримки хостингу, але в цілому можуть виявитися корисними якщо не для всіх, то для багатьох. Тому я адаптував текст лекції, щоб поділитись тут.
Немає значення, як називається ваша посада — важливо, що за фактом ви займаєтеся адмініструванням. Тому почнемо із того, чим має займатися системний адміністратор. Основне його завдання - це упорядкування, підтримання порядку і підготовка до майбутніх збільшення порядку. Без системного адміністратора на сервері починається бардак. Логи не пишуться, або в них пишеться не те, ресурси розподіляються неоптимально, диск заповнюється всіляким сміттям та система починає повільно загинатися від такої кількості хаосу. Спокійно! Системні адміністратори у вашій особі приступають до вирішення проблем та усунення бардаку!
Стовпи системного адміністрування
Однак, перш ніж приступати до вирішення проблем, варто познайомитися з чотирма основними стовпами адміністрування:
- Документацією
- Шаблонізацією
- Оптимізацією
- Автоматизацією
Це є основою основ. Якщо не будувати свій робочий процес на цих принципах, він буде неефективним, непродуктивним та взагалі мало схожим на справжнє адміністрування. Давайте розберемося з кожним окремо.
Документація
Документація має на увазі під собою не читання документації (хоча без цього нікуди), а й ведення.
Як вести документацію:
- Зіткнулися з новою проблемою, яку ніколи не бачили? Запишіть основні симптоми, способи діагностики та принципи усунення.
- Вигадали нове елегантне вирішення типової проблеми? Запишіть його, щоб не довелося винаходити його заново через місяць.
- Вам допомогли розібратися із питанням, у якому ви нічого не розуміли? Запишіть основні тези та концепції, намалюйте собі схему.
Основна ідея: не варто цілком довірятися власної пам'яті під час освоєння та застосування нового.
В якому форматі ви це робитимете, залежить тільки від вас: це може бути система із нотатками, особистий блог, текстовий файл, фізичний блокнот. Головне, щоб ваші записи відповідали таким вимогам:
- Не бути надмірно довгими. Виділяйте основні ідеї, методи та засоби. Якщо розуміння проблеми вимагає пірнути в низькорівневу механіку роботи виділення пам'яті в Linux, не переписуйте статтю, з якої ви її впізнали, дайте на неї посилання.
- Записи мають бути зрозумілими для вас. Якщо рядок
race cond.lockupне дозволяє вам відразу зрозуміти, що ви цим рядком описали - поясніть. У добрій документації не треба розбиратися по півгодини. - Пошук – дуже хороша фішка. Якщо ви ведете записи у блозі, додавайте теги; якщо у фізичному блокноті – приклеюйте маленькі post-it із описами. Немає особливого сенсу в документації, якщо ви на пошук відповіді в ній витрачаєте стільки часу, скільки витратили б на вирішення питання з нуля.
Ось так може виглядати документація: від примітивних записів у блокноті (картинка вище), до повноцінної розрахованої на багато користувачів бази знань з тегами, пошуком і всіма можливими зручностями (нижче).
Вам не тільки не доведеться шукати одні й самі відповіді двічі: документування буде чудовою підмогою у вивченні нових тем (конспекти ж!), прокачає ваше павукове чуття (здатність діагностувати складну проблему, кинувши один поверховий погляд), додасть організованості у ваші дії. Якщо документація буде доступна вашим колегам, то дозволить їм розібратися, що і як ви нагородили, коли вас не буде на місці.
Шаблонізація
Шаблонізація - Це створення та використання шаблонів. Для вирішення більшості типових питань варто створити певний шаблон дій. Для діагностики більшості проблем слід використовувати стандартизовану послідовність дій. Коли ви щось полагодили/встановили/оптимізували, працездатність цього чогось варто перевіряти за стандартизованими чек-листами.
Шаблонізація - найкращий спосіб організації робочого процесу. Використовуючи типові процедури для вирішення найчастіших проблем, ви отримуєте багато класного. Наприклад, використання чек-листів дозволить вам діагностувати всі важливі для роботи функції та відкинути діагностику маловажливої функціональності. А стандартизовані процедури зведуть до мінімуму непотрібні метання та зменшать ймовірність помилки.
Першим важливим моментом є те, що процедури та чек-листи теж потрібно документувати. Якщо просто сподіватися на згадку, можна пропустити якусь реально важливу перевірку чи операцію і все розвалити. Другий важливий момент - всі шаблонні практики можна і потрібно модифікувати, якщо цього вимагає ситуація. Ідеальних та абсолютно універсальних шаблонів немає. Якщо проблема є, а шаблонна перевірка її не виявила це не означає, що проблеми немає. Однак перш ніж братися за перевірку якихось малоймовірних гіпотетичних проблем, завжди варто спершу зробити швидку шаблонну перевірку.
Оптимізація
Оптимізація каже сама за себе. Робочий процес потрібно максимально оптимізувати у плані час-і трудовитрат. Тут варіантів безліч: вивчіть гарячі кнопки, скорочення, регулярні висловлювання, доступні інструменти. Шукайте варіанти більш практичного використання цих інструментів. Якщо ви 100 разів на день викликаєте команду, повісьте її на скорочення клавіатури. Якщо вам потрібно регулярно підключатися до тих самих серверів, запишіть або в одне слово, яке буде вас туди підключати:
Ознайомтеся з різними варіантами доступних інструментів — можливо є більш зручний термінальний клієнт, DE, менеджер буфера обміну, браузер, поштовий клієнт, операційна система. Дізнайтеся, якими інструментами користуються ваші колеги та знайомі – може, вони вибирають їх не просто так. Після того, як ви підберете інструменти, навчитеся їх застосовувати: вивчіть ключі, скорочення, tips and tricks.
Оптимально використовуйте стандартні інструменти - coreutils, vim, регулярні вирази, bash. Для останніх трьох є безліч чудових мануалів і документація. З їхньою допомогою можна досить швидко перейти від стану «я відчуваю себе мавпою, яка коле горіхи ноутбуком — до «я мавпа, яка використовує ноутбук, щоб замовити собі горіх».
Автоматизація
Автоматизація перенесе важкі операції з наших втомлених рук до невтомних рук автоматики. Якщо якась стандартна процедура виконується в п'ять однотипних команд, то чому б не обернути всі ці команди в один файл і не кликати одну команду, яка цей файл качає і виконує?
Власне автоматизація на 80% складається з написання та оптимізації своїх власних інструментів (і ще на 20% зі спроб змусити їх працювати як слід). Це може бути просто просунутий однострочник або велика всемогутня тулза з веб-інтерфейсом і API. Головний критерій тут - створення інструменту має займати не більше часу та зусиль, ніж кількість часу та зусиль, які вам цей інструмент заощадить. Якщо ви п'ять годин пишете скрипт, який вам більше ніколи не стане в нагоді, для завдання, на вирішення якого у вас без скрипта пішла б година-друга — це дуже погана оптимізація робочого процесу. Можна витратити п'ять годин створення інструменту, тільки якщо кількість, тип завдань і час це дозволяють, що буває нечасто.
Автоматизація необов'язково передбачає написання повноцінних скриптів. Наприклад, щоб створити купу однотипних об'єктів зі списку, досить спритного однорядника, який автоматично зробить те, що ви робили б руками, перемикаючись між вікнами, з купами копіпаста.
Власне, якщо побудувати процес адміністрування цих чотирьох стовпах, можна досить швидко підвищити свою ефективність, продуктивність і кваліфікацію. Однак цей список потрібно доповнити ще одним пунктом, без якого робота в IT практично неможлива – самоосвітою.
Самоосвіта сисадміну
Щоб бути в цій сфері хоч трохи компетентними, потрібно постійно вчитися і впізнавати нове. Якщо у вас немає найменшого бажання стикатися з невідомим і розбиратися, ви дуже швидко просядете. У IT постійно з'являються нові рішення, технології та методи, і якщо ви не вивчаєте їх хоча б поверхово - ви на шляху до програшу. Багато сфер інформаційних технологій стоять на дуже складному і об'ємному базисі. Наприклад, робота мережі. Мережі та інтернет є скрізь, ви стикаєтеся з ними щодня, але варто копнути в технології, які стоять за ними, ви виявите величезну та дуже складну дисципліну, вивчення якої – жодного разу не прогулянка у парку.
Я не став включати цей пункт до списку, тому що він є ключовим для IT загалом, а не лише для системного адміністрування. Звичайно, вивчити абсолютно все і відразу не вийде - у вас просто фізично не вистачить часу. Тому при самоосвіті слід пам'ятати про необхідні рівні абстракції.
Вам необов'язково відразу вчити, як працює внутрішній менеджмент пам'яті у кожної окремо взятої утиліти, і як він взаємодіє з менеджментом пам'яті Linux, але ось що оперативна пам'ять являє собою схематично, і навіщо вона потрібна, знати непогано. Вам необов'язково знати, як структурно відрізняються заголовки TCP і UDP, але було б непогано розуміти основні відмінності протоколів у роботі. Вам не потрібно вивчати, що собою представляють згасання сигналу в оптиці, але було б непогано знати, чому справжні втрати завжди успадковуються по вузлах. Немає нічого поганого в тому, щоб знати, як працюють певні елементи на певному рівні абстракції і необов'язково розбирати абсолютно всі рівні, коли абстракції немає взагалі (ви просто звихнетеся).
Однак у своїй галузі міркувати на рівні абстракції «ну це така штука, яка дозволяє показувати сайтики» – не дуже добре. Наступні лекції будуть присвячені огляду основних областей, із якими системному адміністратору доводиться зіштовхуватися у роботі нижчих рівнях абстракції. Я постараюся обмежити кількість знань, що оглядаються, мінімальним рівнем абстракції.
10 заповідей системного адміністрування
Отже, ми засвоїли чотири основні стовпи та фундамент. Чи можна починати вирішувати проблеми? Ще немає. Перед цим бажано ознайомитись із так званими «best practices» та правилами гарного тону. Без них є можливість, що ви принесете більше шкоди, ніж користі. Тож почнемо:
- Деякі мої колеги вважають, що найперше правило — «не нашкодь». Але я схильний не погодитись. Коли намагаєшся не нашкодити, то й зробити нічого не можеш — надто багато дій є потенційно деструктивними. Найважливішим правилом я вважаю «зроби бекап». Навіть якщо нашкодиш, завжди можна буде відкотитись, і все буде вже не так погано.
Бекапит потрібно завжди, коли час і місце дозволяють це. Бекапити потрібно те, що ви мінятимете і те, що ви ризикуєте втратити при потенційно деструктивній дії. Бекап бажано перевірити на цілісність та наявність усіх потрібних даних. Бекап не варто видаляти відразу після того, як ви все перевірили, якщо не потрібно звільнити місце на диску. Якщо місце вимагає – забекапте на ваш особистий сервер і видаляйте за тиждень.
- Друге за важливістю правило (яке я сам часто порушую). «не приховуй». Якщо ви зробили бекап, напишіть, куди, щоб вашим колегам не доводилося його шукати. Якщо ви зробили якісь неочевидні чи складні дії, запишіть: ви підете додому, а проблема може повторитися або виникнути у когось іншого і ваше рішення знайдуть за ключовими словами. Навіть якщо ви робите щось добре знаєте, цього можуть не знати ваші колеги.
- Третє правило пояснювати не треба: «ніколи не роби того, наслідки чого ти не знаєш, не уявляєш чи не розумієш». Не копіюй команди з інтернету, якщо не знаєш, що вони роблять, поклич man і розпари спочатку. Не застосовуй готових рішень, якщо не можеш зрозуміти, що вони роблять. Зведи до абсолютного мінімуму виконання обфусцованого коду. Якщо часу розбиратися немає - то ви щось робите не так і вам слід ознайомитись з наступним пунктом.
- «Тестуй». Нові скрипти, інструменти, однострочники та команди слід перевіряти в контрольованому середовищі, а не на клієнтській машині, якщо там є хоча б мінімальний потенціал до деструктивних дій. Навіть якщо ви все забекапіли (а ви це зробили), даунтайм – не найкласніша справа. Заведіть для цієї справи окремий сервак/віртуалку/chroot та тестуйте там. Нічого не зламалося? Тоді можна запускати на "бойовому".
- «Контролюй». Зведіть до мінімуму всі операції, які ви не контролюєте. Одна крива залежність пакета може стягнути у себе половину системи, а виставлений для yum remove прапор -y, дає можливість потренувати свої навички відновлення системи з нуля. Якщо дія не має безконтрольних альтернатив — наступний пункт і готовий бекап.
- «Перевіряй». Перевіряйте наслідки своїх дій і чи потрібно відкотитись на бекап. Перевіряйте, чи справді проблема вирішилася. Перевіряйте, чи відтворюється помилка і за яких умов. Перевіряйте, що ви можете розламати своїми діями. Довіряти в нашій роботі зайве, а от перевіряти ніколи.
- «Спілкуйся». Якщо не вдається вирішити проблему, запитайте колег, чи не стикалися вони з таким. Хочете застосувати спірне рішення – дізнайтесь думку колег. Можливо, вони запропонують рішення краще. Немає впевненості у своїх діях – обговоріть їх із колегами. Навіть якщо це ваша експертна область, свіжий погляд на ситуацію може багато прояснити. Не соромтеся свого незнання. Краще поставити дурне питання, здатися дурнем і отримати на нього відповідь, ніж ставити це питання, не отримати відповідь і залишитися в дурнях.
- «Не відмовляй у допомозі безпідставно». Цей пункт – зворотний бік попереднього. Якщо вам поставили дурне питання - проясніть і пояснити. Просять нездійсненного - поясніть, що воно нездійсненне і чому, пропонуйте альтернативи. Якщо немає часу (реально немає часу, а не бажання) - скажіть, що у вас є термінове питання великий обсяг роботи, але ви розберетеся пізніше. Якщо колеги не мають термінових завдань, запропонуйте звернутися до них і делегуйте питання.
- «Давай фідбек». Хтось із колег почав застосовувати нову методику чи новий скрипт, а ви зустрічаєтеся з негативними наслідками цього рішення? Повідомте про це. Можливо, проблема вирішується у три рядки коду або п'ять хвилин доопрацювання методики. Натрапили на баг у ПЗ? Повідомте про баг. Якщо він відтворюється або немає необхідності відтворювати, його, швидше за все, пофіксують. Озвучуйте побажання, пропозиції та конструктивну критику, виносьте питання на обговорення, якщо здається, що вони є актуальними.
- «Проси фідбека». Ми всі неідеальні, як і наші рішення, а найкращий спосіб перевірити правильність свого рішення винести його на обговорення. Заоптимізували щось у клієнта — попросіть простежити за роботою, може «пляшка» у системи не там, де ви шукали. Написали скриптик-допомогу — покажіть колегам, може, вони знайдуть спосіб його покращити.
Якщо постійно застосовувати ці практики в роботі, більшість проблем перестає бути проблемами: ви не просто зведете кількість своїх власних помилок і факапів до мінімуму, але й матимете можливості виправити помилки (в особі бекапів та колег, які вам порадять забекапити). Далі лише технічні деталі, в яких, як відомо, і криється диявол.
Основні інструменти, з якими вам доведеться працювати більше 50% часу – grep та vim. Що може бути простішим? Пошук за текстом та редагування тексту. Однак і grep, і vim – найпотужніші багатофункціональні мультитули, які дозволяють шукати та редагувати текст ефективно. Якщо якийсь віндовий notepad дозволить вам просто написати/видалити рядок, то у vim'і можна робити з текстом майже що завгодно. Не вірите - викличте з терміналу команду vimtutor і починайте вивчати. Що ж до grep — основна його сила у регулярних виразах. Так, сам інструмент дозволяє досить гнучко задавати умови пошуку і дані, що виводяться, але без RegExp це особливого сенсу не має. І регулярні вирази треба знати! Хоча б на базовому рівні. Для початку я б порадив вам подивитися ось це , у ньому розбираються основи основ регулярних виразів та його застосування разом із grep. Так, при поєднанні їх з vim, ви отримуєте ULTIMATE POWER можливість робити з текстом такі речі, що їх доводиться обвішувати значками 18+.
З решти 50%, 40% припадає на пакет інструментів coreutils. Для coreutils список ви можете подивитися в , а мануал до всього списку - на сайті . Що не вкрито цим набором, є в утилітах . Необов'язково заучувати це з усіма ключами напам'ять, але бодай приблизно знати, що можуть основні інструменти — корисно. Не доведеться винаходити велосипед із милиць. Мені якось треба було замінити перенесення рядка на прогалини у висновку від якоїсь утиліти, і хворий мозок породив конструкцію виду sed ':a;N;$!ba;s/n/ /g', що підійшов колега відігнав мене мітлою від консолі, а потім вирішив завдання, написавши tr 'n' ' '.
Я б порадив запам'ятати, що приблизно виконує кожна окрема тулза і ключики до команд, що найчастіше використовуються, для всього іншого є man. Не соромтеся звати man, якщо ви у чомусь сумніваєтеся. І обов'язково прочитайте man на сам man він містить важливу інформацію про те, що ви знайдете.
Знаючи ці інструменти, ви зможете ефективно вирішити значну частину завдань, з якими зіткнетеся на практиці. У наступних лекціях ми розглянемо, коли застосовувати ці інструменти та структури основних служб та додатків, до яких вони застосовуються.
З вами був системний адміністратор FirstVDS Кирило Цвєтков.
Джерело: habr.com