Чому адміністрування баз даних так важко?

Я знаю багато адміністраторів баз даних, і всім їм більше 28-29 років.

Чи все адміністрація бази даних така? Я маю на увазі, це стосується отримання досвіду більше як мінімум 7-8 років?

Або так важко бути адміністратором бази даних?

Позиція вимагає широкого спектру знань, починаючи від розробки до адміністрування системи та навіть управління. Не тільки DBA повинен знати про резервне копіювання, відновлення, внутрішні операції, пам'ять та безпеку, а також про те, як спілкуватися як з розробниками, так і з управлінням. DBA може давати представлення на високому рівні керівництву, допомагаючи розробникові налаштувати запит, забезпечивши дисковий простір для нової системи та відновивши дані з резервного копіювання все протягом тієї ж години. Ці обов'язки вимагають багатства знань з невеликим перекриттям.

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

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

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

Стати DBA фактично вимагає великого досвіду, але в основному це може виходити лише з чотирьох різних напрямків:

1. Будучи розробником та створюючи посилання на DBA
2. Будучи розробником та розробляючись як DBA
3. Навчання прямо з коледжу / торгової школи, щоб стати DBA
4. Будучи SysAdmin та створюючи атаку або виконуючи подвійну службу як DBA

Будучи розробником і перетворюючи сегу в DBA

В іншому запитанні, яке було задано на цьому веб-сайті, « Чи можуть DBA бути більш« сприятливими для програмістів » , я зазначив, що я був розробником 16 років, який працював з DBA. Попрацювавши з ними, я дав мені зрозуміти, що наскільки їхній досвід включає теорію баз даних, дискретну математику та досвід програмування, настільки вони могли бачити, як повинна працювати база даних та як слід виконувати запит.

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

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

Будучи розробником та розробляючись як DBA

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

Нова DBA тепер може створювати власні таблиці та індекси. Це могло б нагадувати, як японський Хібачі готувався до італійського ресторану. Кухар може збити все, що завгодно, але повинен усвідомити, що є нові рецепти, кухонне начиння, столові прибори, м'ясо, спеції, овочі та безліч інших щоденних речей, до яких слід підлаштовуватися (санітарія, інвентар, час початку роботи, години роботи тощо). Це не просто час переходу, а й час подолання великої кривої навчання. Новий досвід має бути засвоєний та розвинутий, незважаючи на те, що японська кухня готувала протягом багатьох років. У цьому аспекті розробники повинні знову привчати себе до думки як DBA.

Навчання прямо з коледжу / торгової школи, щоб стати DBA

Це, безумовно, самий смертельний спосіб стати DBA. Це також найрідкісніший шлях - насправді це практично не чутно. Зараз ми говоримо про те, щоб пустити когось із Макдональдса чи Бургер Кінга в той самий італійський ресторан.

Три криві навчання:

1. Застосування навичок коледжу / торгової школи в ролі DBA,
2. Взаємодія з конкретними RDBMS (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres) та,
3. Взаємодія з розробниками ( майбутня DBA, яка навчається гідним соціальним навичкам прямо поза школою? Так, так! ).

У цьому розробники будуть роками переважати DBA. DBA повинні навчитися швидко адаптуватися до потреб розробників у перші роки, як DBA. Можливо, DBA могла б отримати гідну стартову зарплату, але важче зростати, не розвиваючись у цих трьох сферах навчання.

Будучи SysAdmin та підробляючи напади або виконуючи подвійний обов'язок як DBA

Як колишній розробник, а тепер DBA, одна річ, яку не слід сприймати як належне, - це роль SysAdmin.

Виконання ролі SysAdmin / DBA для мене трохи вражає. У хостинговій компанії мого роботодавця є хлопець, який є SysAdmin / DBA (SCMDBA). Він так завалений інфраструктурними проектами плюс власні внутрішні концерти MySQL. Я йому не заздрю, я його вітаю. Чесно кажучи, оскільки справжній розум SysAdmin / DBA мені чужий, я залишаю це на розсуд SysAdmin / DBA, щоб оновити цей параграф (або повністю замінити його) для опису цього шляху .

Висновок

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

До речі, саме так трапляється, я пережив перші два шляхи до DBA, починаючи з серпня 2004 року у віці 39 років. Два роки досвіду роботи у складі ролі DBA зробили перехід на штатну DBA дуже приємним та комфортним .

Моя порада DBA 28-29 років? Будьте так само хороші в роботі з людьми, як і з RDBMS. Якщо ви росте в обох районах, ви можете зробити це DBA на довгі роки.

Адміністрація бази даних є складною з двох причин

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

Дорогі помилки Це також причина того, що генеральні директори великих компаній, як правило, у 50-х роках.

Бути поганим DBA досить легко

Серйозно, хоча DBA зазвичай несе особливу відповідальність за те, що часто є критичним для успіху чи провалу бізнесу: його дані

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

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

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

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

Крім того, легко вивчити команди з книги для резервного копіювання / відновлення бази даних, оптимізувати конфігурацію сервера тощо. Але досвід виграє, коли ви отримаєте сповіщення про те, що ваша база даних не працює.

Я знаю багато адміністраторів баз даних, і всім їм більше 28-29 років. Чи все адміністрація бази даних така?

Більшість хороших, солідних програмістів, яких я знаю, також не менше 25 років. Я думаю, є коефіцієнт, що корелює з віком + досвід = хороший кодер. ;)

Я маю на увазі, це стосується отримання досвіду більше як мінімум 7-8 років? Або так важко бути адміністратором бази даних? Що ти думаєш?

Бути адміністратором бази даних непросто, якщо це саме так. Є багато речей, які слід знати як dba. Це також означає школу, а це означає кілька років опіки над іншою людиною. Пам’ятайте, що бази даних є заданою логікою, про яку майже ніхто не ходить у школу досить довго, аби цього ніхто не знав. Set-логика поділяє деякі правила з алгеброю, але двигуни (MSSQL, Oracle тощо) самі по собі є перекрученими звірами реалізації цих правил, тому не тільки ви повинні розуміти математику за базами даних, ви повинні розуміти реалізацію, яку ви бігати поверх. Це навіть не зараховує знання бажаної мови сценаріїв (PL / SQL, TSQL тощо).

Тоді врахуйте, що як dba ви будете нести відповідальність за те, щоб найважливіші бізнес-дані часто були доручені вашим руках. Вам потрібно пройти повз найгірших частин "помилкових помилок", і вам потрібно було трохи навчитися самообмеження. Більшість людей у ​​21-23 років ще цього не дізналися. Деякі з нас у 30 років ще не мають.

ОТ: Тому я кажу, що люди насправді нічого не знають, поки їм не менше 40, і тоді вони вважаються за пагорбом, коли насправді вони просто досягають свого кроку. (сказано як хтось 31)

Я не думаю, що бути DBA важко. Стати одним було все-таки.

Я хотів відповісти, щоб додати ще один аспект, який недостатньо обговорювався вище: поле зору.

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

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

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

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

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

Є ще один шлях, трохи інший за формою перерахованих.

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

PS: Коли я колишній програміст перетворився на DBA, програмісти запитували мене: "чи робота DBA нудна?"

Моя відповідь: «нудно лише тоді, коли ти робиш це правильно!». :)

Я, скоріше, починаю свою подорож до DBA, але ось декілька причин, чому люди можуть важко знайти цю роботу ... Важко тому, що:

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

Бред Мак Геї написав про це книгу "Як стати винятковою DBA". Варто прочитати, якщо ви маєте намір поглибити питання.

Удачі!

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

Я скажу, що все, що я мав, - це ступінь психології та довідкова служба. Коли я отримав роботу DBA в Oracle Apps, я одразу подумав про OMG, всі речі, на які я вчився, щоб стати CORE DBA, ні на один раз не допомогли мені. Пам’ятаю, відчував себе надзвичайно переповненим. Мені довелося щодня нагадувати собі, що я можу це навчитися, і через 2 роки я здобув набагато більше знань.

Що я говорю, це бути DBA - це не важко, зовсім не важко, але вивчити все на роботі і поза роботою, про що ми повинні знати, як згадували попередні dba, займає багато часу і вимагає багато зусиль. Я виявив, що в 27 років більшість людей мого віку чи молодшого не мають ані старання, ані бажання хотіти вивчати такий великий спектр технологій. Але я люблю свою роботу в якості Oracle Apps DBA і з нетерпінням чекаю всього іншого, що постійно буде кинутий мені шлях до навчання. Ви можете це зробити, якщо ви подумаєте про це, не важливо, у якому віці ви!

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

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

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

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

Щоб бути хорошим DBA, вам також потрібна впевненість і зрілість, яка, як правило, з віком. Інші перелічили інші аспекти цього, але я додам впевненості сказати «ні» і витримати свою позицію, загартовану досвідом, щоб знати, коли це доречно.

Нарешті, я думаю, що хороший DBA вимагає певного розуму, і важко дізнатися, чи є у вас, поки ви не потрапили в окопи. Ознайомлення з деталями, готовність планувати заздалегідь, вміння дивитись на велику картину і не боятися документувати свою роботу - важливі аспекти підтримки стабільної системи. Деякі SysAdmins та Developers подібні до цього і можуть легко здійснити перехід, тоді як інші можуть виявити, що, хоча їхній підхід має значення в їхній поточній роботі, як DBA вони будуть боротись і вважати ці речі справжніми справами, а не отримувати задоволення від роботи.

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

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

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

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

Якщо я коли-небудь стану адміністратором бази даних, я буду оновлювати те, що зараз написав тут.

І так, мені зараз 38 + 1/2 років.

Як і більшість навичок, навчання бути dba вимагає часу. Стати хорошим dba потрібно більше часу. Чим більше ви читаєте та вивчаєте, тим більше знань можете застосувати.

Ще один шлях до становлення ДБА - це написання звітів або як експерт із додатків. Чим більше часу ви витрачаєте руками на SQL, тим більше ви дізнаєтесь про те, як працює dbs. Отримавши знання в SQL-запитах, ви зможете стати доброю відправною точкою для становлення dba.