Скільки мають мати доступ розробники? [зачинено]

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

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

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

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

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

У розробників не повинно бути виробничих прав на запис даних або прав на створення об'єктів. Нічого не слід продавати, що не є частиною офіційного релізу. Занадто багато разів люди роблять швидке виправлення продукту, який або не працює, що призводить до того, що prod ще більше приглушиться або працює, але вони забувають ввести код на сервери dev / QA / Staging і ще гірше - у джерело контрольного сховища, і код буде перезаписаний приблизно через місяць у наступному офіційному випуску.

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

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

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

Що ж, це справді питання про "Вампірів (програмістів) проти" перевертень (сисадмінів) ", як тут це поставив Джефф Етвуд .

Зазвичай (це означає, що існує розкіш, щоб налаштувати повноцінне середовище), розробник отримує доступ до:

• Виробничий сервер
  • Ніхто (SA / PM не застосовуватиметься для налаштування схеми, кінцевий користувач надасть дані про init)
• UAT-сервер
  • Жоден (SA / PM застосовуватиметься для налаштування схеми та вибірки даних вибірки)
• Тестування / QA-сервер
  • Зазвичай розробник надсилає сценарій настройки схеми команді QA, а QA створює таблиці
  • Розробники мають повний доступ до баз даних, але їх рідко змінюють
  • Розробники можуть допомогти колегам з питань контролю якості виправити / виправити / видалити деякі дані
• Сервер розробки / localhost
  • Повний доступ

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

Абсолютний мінімум, який вам потрібен, щоб виконати роботу.

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

Якщо ваша робота в основному може бути виконана без доступу до запису БД (а я маю на увазі максимум кілька запитів на зміну на тиждень), то вам дійсно не потрібен доступ до запису.

У всіх робочих умовах є 2 конкуруючих бажання.

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

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

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

Розробники повинні мати повний доступ до баз даних розробників (в ідеалі вони повинні працювати на локальному сервері, але це не завжди можливо). Вони повинні мати доступ до бази даних build / QA, але лише до даних (для зміни структури потрібно мати дозвіл / подати квиток). Розробники ніколи не повинні мати випадковий доступ до виробничої бази даних (якщо це не невелика компанія / проект, і розробники також не підтримують виробництво).

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

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

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

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

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

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

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

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

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

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

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