Як DBA можуть бути більш "дружніми до програмістів"?

Відповіді та зауваження до версії dba.se та версії programmers.se на питання "Які аргументи проти або для введення логіки програми в рівень бази даних?" дуже розкриваються про розрив між DBA та програмістами на деяких робочих місцях.

Що може зробити DBA по-різному, щоб краще працювати з програмістами з таких питань?

Чи варто нам:

• Вивчіть інструменти та мови, якими користуються наші програмісти, щоб зрозуміти їх труднощі, особливо під час роботи з добре розробленими базами даних?
• Заохочуйте програмістів бути більш освіченими щодо баз даних та переваг наявності ділової логіки на рівні бази даних?
• Змінити спосіб визначення інтерфейсів для наших даних - наприклад, за допомогою більш зручних для програмістів транзакційних API (наприклад, для таких питань, як зворотна сумісність)?

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

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

Я був DBA MySQL протягом останніх 6,5 років. Я також провів десь 16 років як розробник і спілкувався з багатьма DBA. Багато з них прагматичні. Деякі з них недоброзичливі. Мало хто не має поняття, що означає бути DBA.

Я прийшов до такого висновку:

Технічно кажучи, найкращі для роботи ДБА, які мають одну або декілька з наведених нижче якостей:

1. Провели роки як самі розробники
2. Усвідомити теорію баз даних
3. Добре розуміти, як RDBMS працює всередині
4. Майте чудові знання про операційну систему

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

Що стосується особистостей, то завжди будуть конфлікти, дріб'язковість і, можливо, навіть заздрість. Одне напевне: в жодному порядку не покладається, що DBA та розробники - це як чоловіки і дружини (я був щасливо одружений 16 років з поточними проектами [4 дітей]).

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

1. треба проконсультуватися з іншим
2. треба цінувати перспективу іншого
3. треба приймати рішення на благо обох сторін
4. треба підтримувати прийняте рішення, а не саботаж
5. не слід заперечувати інше, якщо рішення призводять до поганих наслідків
6. треба радіти внеску обох сторін в успіх рішень
7. необхідно проконсультуватися з вищим органом (HA), якщо рішення не може бути узгоджено взаємно

Ці сім (7) принципів застосовуються так само на робочому місці, особливо в сфері ІТ.

Повідомляючи кожен крок, усі повинні:

1. макет своїх очікувань
2. викликати повагу до здатності іншої сторони виконувати свою роль на основі результатів минулого
3. мати довіру та впевненість у тому, що інша сторона може виконати своє завдання
4. Виправдайте наші власні очікування
5. закупівлі під керівництвом НА (див. принцип № 7)

В цьому немає місця для мікроменеджменту. DBA не повинні розповідати розробникам, як мислити як DBA. Розробники НЕ повинні говорити DBA, як бути розробниками. Остаточні рішення щодо продуктивності та використання бази даних повинні покладатися на DBA . Остаточні рішення щодо потреб у програмі повинні покладатися на розробників . Цей симбіоз потрібно підтримувати завжди.

ЗАКЛЮЧНІ МИСЛИ

Принцип №7 вимагає активної участі та нагляду з боку ВИЩОЇ ВЛАДИ (НАТО), тобто керівника проекту, керівника команди, головного розробника. Ваш НАЗ краще знає, як обидві сторони працюють окремо і як обидві сторони повинні працювати разом. Якщо НАС не встановить основні правила для обох сторін, або якщо ВА не зможе керувати сторонами окремо і разом, проекти завжди будуть припинятися в якийсь момент і загрожувати самому існуванню (працевлаштуванню) Розробника, DBA, або навіть HA.

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

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

Спілкування віч-на-віч, особливо при обміні ідеями, набагато ефективніше, ніж електронна пошта, і менше шансів викликати важкі почуття через непорозуміння.

Такі речі сильно різняться від місця до місця. На моєму нинішньому сайті лінія між розробниками та DBA дуже розмита - ми (DBA) теж пишемо PL / SQL, і вони (розробники) розсікають плани запитів. Усі ми бачимо себе однолітками, просто з різними наборами та обов'язками. Це дуже цікаво: нещодавно компанія вискочила на борт прокладки DevOps . Спільнота баз даних взагалі цього не розуміє; ми завжди працювали так. Зайве говорити, що ми працюємо надзвичайно продуктивно: рівень баз даних на сьогоднішній деньнайнадійнішою складовою частиною технології компанії є її простота в експлуатації (оскільки ми маємо навички в команді DBA, щоб зрозуміти програму на глибокому рівні, а розробники піддаються впливу DBA, щоб зрозуміти 24/7/365 операції та як щоб структурувати свої додатки для цього).

Але я знаю, що ви маєте на увазі, коли ви говорите про "неправильний" сорт розробника. Він самоучка, що саме по собі є шляхетною справою, але по дорозі він підбирає недовіру до будь-яких офіційних інструкцій. Він не знає, чого не знає , і обурюється тим, хто намагається його просвітлити, він вважає це образою своїх навичок самонавчання. Він навчився імперативному стилю програмування, тому що ви можете навчитися цьому без будь-якого з цих теоретичних речей, про які типи CS завжди лають (ну, погано; всі повинні знати big-Oта подібні біти теорії). Він також навчився трохи OO, просто тому, що йому потрібно використовувати Java. Але хороший професіонал баз даних - розробник або DBA - повинен комфортно мислити в декларативному стилі, обмірковуючи теорію множин, нормальні форми, навіть вміючи розуміти реляційну алгебру і обчислення. Спілкуватися з цими людьми дуже і дуже важко, оскільки вони активно ворожать до всього, що може вивести їх із зони комфорту, що в основному обмежується тим, як щось відформатувати на веб-сторінці. Якщо вони взагалі думають про бази даних, вони думають, що таблиця - це як клас, а рядок - як об’єкт. Ці хлопці буквально просто роблять SELECT * FROM TABLEі фільтрують та сортують результати у власному коді. Вони насправді, насправді не розуміють, чому база даних краще, ніж плоский файл (і вони не так-то таємно думають, що кожен, хто використовує реляційну базу даних, - ідіот).

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

Табір MySQL давно був таким; вони би сказали, що вам не потрібні транзакції, іноземні ключі тощо, якщо ви думали, що це зробили, тільки тому, що ви не мали уявлення, що ви робите, тощо, тощо, тощо (тоді, коли вони виросли, вони спокійно додали їх). Це такі люди, для яких ORM, такі як ActiveRecord або Hibernate, були розроблені, щоб вони могли писати програми баз даних, не потребуючи дотику до SQL. Використання цих технологій я вважаю червоним прапором - це не компанія, яка цінує навички DBA. Те, що вони насправді хочуть, - це няня ...

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

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

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

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

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

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

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

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

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

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

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

Протягом багатьох років, відколи я почав працювати з SQL Server (1998), у мене було багато розробників, які мені підказували, як робити свою роботу. Цікаво, що всі вони знають більше, ніж я, а також є чудовими розробниками .net. Насправді вони теж архітектори і повинні робити більше справ, ніж маніпулювання кодом.

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

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

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

... Спільна тема, правильно ... Спілкування ... спілкування ... спілкування.

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

Як заявляв @Rolando, розробники та DBA повинні розуміти один одного. Коли все зводиться до цього, ми обидва говоримо "Ones & Zeros" - ви б подумали, що це було б добре. У нас є дві сфери відповідальності: DBA мають дані, розробники отримують решту комп’ютера. Але без даних програмістам насправді не було б багато чого зробити.

У нас немає DBA, а часом боляче. Цей шматок мене, який хотів бути DBA десятиліття тому, заграє, коли я побачу деякі речі, які ми робимо. Якби ми завтра найняли DBA, я думаю, я би поцілував ту саму землю, на яку він / вона ходив.

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

Хто тут винен? Пані спілкування.

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

Так, команди повинні поговорити (і слухати) один одного, але менеджер проекту / продукту повинен створити середовище, в якому це може статися.

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

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

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

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

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

Трохи смирення може допомогти для когось із вас. ;)

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