Các nhà phát triển có nên được phép truy vấn ( SELECT/ chỉ đọc) cơ sở dữ liệu sản xuất không? Nơi trước tôi làm việc, nhóm phát triển có db_datareadervai trò; nơi tôi làm việc bây giờ, nhóm phát triển thậm chí không thể kết nối với thể hiện sản xuất.

Một trong những trường hợp thử nghiệm là một bản sao của sản xuất được khôi phục từ bản sao lưu sản xuất mỗi tuần một lần, do đó, không có bất kỳ vấn đề nào với các nhà phát triển thực sự nhìn thấy dữ liệu.

Có lý do chính đáng nào cho việc không cho phép các nhà phát triển truy vấn sản xuất (ngoại trừ đơn giản là không muốn họ có quyền truy cập để đọc dữ liệu nhạy cảm)?

Nó thực sự phụ thuộc vào việc nhà phát triển có bất kỳ trách nhiệm hỗ trợ nào không. Nếu họ đang ở trên móc để hỗ trợ dòng thứ ba thì có lẽ họ sẽ cần phải xem cơ sở dữ liệu sản xuất để làm điều này.

Nói chung, đó là một ý tưởng tồi để làm bất cứ điều gì trên một máy chủ sản xuất trừ khi thực sự cần thiết phải làm điều đó ở đó.

Đối với hầu hết các mục đích phát triển, gương hoặc ảnh chụp nhanh của cơ sở dữ liệu sản xuất sẽ đầy đủ và có thể tốt hơn cơ sở dữ liệu sản xuất trực tiếp. Nếu bạn đang làm bất cứ điều gì liên quan đến tích hợp thì bạn sẽ muốn môi trường cơ sở dữ liệu ổn định nơi bạn có thể kiểm soát những gì trong đó. Bất cứ điều gì liên quan đến hòa giải cũng sẽ cần khả năng nhìn vào một điểm được kiểm soát kịp thời.

Nếu vấn đề là bạn không có môi trường nhân bản sản xuất hoặc bất kỳ phương tiện nào để đặt một bản sao dữ liệu sản xuất ở đâu đó cho các nhà phát triển của bạn thì đây là một câu hỏi hơi khác. Trong trường hợp đó, các nhà phát triển của bạn thực sự cần ít nhất một môi trường nhân bản. Nếu bạn không thể thấy vấn đề trong dữ liệu thì thật khó để khắc phục sự cố.

Không.

Các nhà phát triển không nên có quyền truy cập vào các hệ thống cơ sở dữ liệu sản xuất vì những lý do sau:

1. Tính khả dụng và hiệu suất : Có quyền chỉ đọc đối với cơ sở dữ liệu không phải là vô hại. Một truy vấn kém bằng văn bản có thể:

   1. Khóa bảng, chặn các quá trình quan trọng khác.
   2. Bỏ bộ nhớ cache dữ liệu của bạn, buộc các quá trình khác đọc lại dữ liệu từ đĩa.
   3. Đánh thuế lớp lưu trữ của bạn, tác động đến các dịch vụ khác chia sẻ lưu trữ đó.

2. Bảo mật : Cơ sở dữ liệu sản xuất của bạn có thể chứa thông tin nhạy cảm như:

   • băm mật khẩu
   • Thông tin thanh toán
   • thông tin nhận dạng cá nhân khác

   Chỉ những người thực sự cần truy cập vào thông tin này nên có nó. Trong một công ty được tổ chức tốt, các nhà phát triển không nằm trong số những người đó. Hơn nữa, công ty của bạn sẽ không tuân thủ PCI và SOX nếu các nhà phát triển của nó có thể truy cập các hệ thống sản xuất với dữ liệu này.

   Những lý do cho điều này là rõ ràng. Công việc phát triển của một nhà phát triển trải qua nhiều bàn tay trước khi nó đi vào hoạt động. Điều gì để ngăn chặn một nhà phát triển độc hại với quyền truy cập sản xuất trực tiếp đánh cắp dữ liệu sản xuất của bạn hoặc đưa cơ sở dữ liệu trực tiếp của bạn đến đầu gối?

   "Nhưng điều đó cũng đúng với các DBA! Họ có thể làm điều đó!" Chính xác. Bạn muốn càng ít siêu nhân càng có trách nhiệm.

Đúng.

Các nhà phát triển nên có quyền truy cập vào các hệ thống sản xuất.

Tại công ty của tôi, chúng tôi có bốn đội liên quan đến cơ sở dữ liệu sản xuất. Họ đang:

1. Các nhà phát triển , người thiết kế và viết lược đồ và mã cho cơ sở dữ liệu. Họ không có quyền truy cập vào cơ sở dữ liệu trong sản xuất. Tuy nhiên, đôi khi họ ngồi với Quản trị viên hoặc Người hỗ trợ và giúp họ xem xét một cái gì đó trực tiếp.
2. Quản trị viên , người triển khai, giám sát và quản lý cơ sở dữ liệu trong sản xuất.
3. Hỗ trợ mọi người , những người điều tra các vấn đề sản xuất nhạy cảm với thời gian và cung cấp phản hồi cho các nhà phát triển để họ có thể phát triển các bản sửa lỗi.
4. Những người thông minh trong kinh doanh , những người trích xuất dữ liệu từ cơ sở dữ liệu sản xuất bằng cách sử dụng các bản sao thường xuyên của các cơ sở dữ liệu đó hoặc trích xuất cẩn thận và trích xuất QA-ed (thường được thiết kế bởi Quản trị viên).

Rất thích hợp để cấp cho nhà phát triển của bạn quyền truy cập khi bạn có một số thiếu sót nhất định trong các nhóm khác này.

Ví dụ:

• Bạn không có nhóm hỗ trợ. Ai sẽ biết nơi để tìm cách gỡ lỗi vấn đề sản xuất nhạy cảm với thời gian đó? Nhà phát triển của bạn. Cấp cho họ quyền truy cập " phá vỡ kính ".
• Bạn không có đội BI. Quản trị viên của bạn không có hoặc muốn làm gì với các báo cáo hoặc trích xuất. Ai sẽ khắc phục sự cố báo cáo mà nhân viên của bạn nhìn thấy mỗi sáng? Nhà phát triển của bạn. Cấp cho họ quyền truy cập hạn chế để gỡ lỗi các báo cáo và trích xuất này.
• Bạn không có đội ngũ quản trị. Bạn đang ở trong một công ty rất nhỏ hoặc khởi nghiệp, vì vậy hãy nói xin chào với "DBA tình cờ". Các nhà phát triển của bạn tăng gấp đôi là quản trị viên của bạn và do đó cần có quyền truy cập đầy đủ vào sản xuất.

Hiệu suất sẽ là một lý do LỚN.

Chỉ vì họ không thể thay đổi dữ liệu không có nghĩa là họ không thể ảnh hưởng đến máy chủ. Một truy vấn kém bằng văn bản có thể khiến môi trường sản xuất quỳ xuống và có thể gây ra các vấn đề khác (như tràn tempdb):

SELECT *
FROM BigTable A, OtherBigTable B
ORDER BY Somecolumn

Đó là một công thức cho thảm họa. Lưu ý rằng đây là một sản phẩm cartesian với một đơn đặt hàng, có nghĩa là nó sẽ được sắp xếp trong tempDB.

Nguyên tắc là "đặc quyền tối thiểu" và "cần biết": các nhà phát triển có vượt qua bài kiểm tra này không?
Đặc biệt là khi Kiểm toán viên hoặc Sarbannes-Oxley đến gõ cửa.

Sau đó, giả định tiếp theo của tôi: các nhà phát triển là ngu ngốc. Vì vậy, nếu họ cần nói để hỗ trợ dòng thứ 3, người sau đó cần nó? Khỉ web thường không có nhưng loại cơ sở dữ liệu có nếu chúng được dự kiến ​​sẽ hỗ trợ nó.

Sau đó, có cần truy cập vĩnh viễn? Họ có thể có quyền truy cập "kính vỡ" bằng cách sử dụng tài khoản đăng nhập SQL hoặc tài khoản Windows thay thế yêu cầu đăng nhập. Trong trường hợp của chúng tôi, đó là chủ sở hữu dữ liệu (một số doanh nhân am hiểu công nghệ hy vọng) và người quản lý CNTT chấp thuận.

Tôi đã thấy các nhà phát triển kiểm tra chống lại hoặc chạy các truy vấn trên sản xuất và gỡ nó xuống vì sự thiếu hiểu biết. Nói rằng, các nhà phát triển nên chịu trách nhiệm cho hành động của họ: nếu họ làm hỏng máy chủ, họ sẽ phải chịu đựng theo. Tôi đã có người bị giáng chức sau một sự cố ...

Tất nhiên, đây là một cửa hàng có kích thước hợp lý. Càng nhiều người dân đội mũ càng ít phân chia nhiệm vụ bạn có thể có

Ngoài ra, có một môi trường mà các nhà phát triển có thể chạy các truy vấn đối với dữ liệu gần đây không? Trong cửa hàng cuối cùng của tôi, prod đã được khôi phục mỗi đêm đến một máy chủ thử nghiệm để cung cấp điều này.

Tôi nghĩ rằng câu trả lời là, giống như với nhiều thứ CNTT, "nó phụ thuộc".

Một cơ sở dữ liệu ERP lớn với nhiều thông tin khách hàng và công ty nhạy cảm? Có lẽ là không (cả vì lý do bảo mật và hiệu suất).

Cơ sở dữ liệu 5 MB của bộ phận với giao diện truy cập theo dõi các đóng góp cho quỹ bánh rán và pizza? Sẽ không tạo ra nhiều sự khác biệt, ít nhất là cho truy cập chỉ đọc.

Cấp, ví dụ đầu tiên là phổ biến hơn nhiều so với thứ hai, nhưng đây là những khác biệt bạn cần lưu ý nếu bạn chịu trách nhiệm đưa ra các loại quyết định chính sách này. Nhưng mặt khác, thật đáng kinh ngạc khi một cơ sở dữ liệu quỹ bánh rán và bánh pizza 5 MB có thể mở rộng nhanh chóng đến một con số 50 GB / số thẻ tín dụng khách hàng / số người biết điều gì- cơ sở dữ liệu khác nếu bạn để nó.

Trên môi trường OLTP 24/7 thông thường, nhà phát triển bình thường không được phép sản xuất. Giai đoạn = Stage! Thỉnh thoảng, nếu một lý do cụ thể xuất hiện, thì các quyền có thể được cấp theo yêu cầu. Nhưng trên cơ sở thông thường không có.

Tôi đã thấy nhiều lý do cho việc này:

• CHỌN * từ một bảng lớn dẫn đến:

  • vấn đề hiệu suất (sản phẩm cartesian);
  • chặn các vấn đề mà cuối cùng đã đưa trang web đến đầu gối;
  • chuỗi chặn đặt bản sao vào một hang;
  • đặt hàng bộ dữ liệu lớn chứa đầy ổ TempDB mà .. không biết sao? Gây ra sự điên rồ hoàn toàn :-)!
  • huyết áp cao cho DBA phụ trách sản xuất cho đêm đó;

• đọc dữ liệu nhạy cảm (nhà phát triển không nên truy cập thông tin thẻ tín dụng..hoặc mọi chi tiết cá nhân của người dùng);

Tôi chắc chắn có nhiều lý do hơn nữa.

• Bảo mật: Có thể có thông tin nhạy cảm được vệ sinh khi họ cung cấp cho nhà phát triển.
• Chứng hoang tưởng: Một số người có thể nghĩ rằng bạn vẫn có thể làm rối dữ liệu chỉ với quyền truy cập được chọn.
• Hiệu suất: Một truy vấn cần một số tài nguyên để thực hiện và bạn không thể cho tôi biết các nhà phát triển của bạn hoàn hảo khi họ viết mã.

Vài mục cần xem xét

• Là dữ liệu nhạy cảm?
• Là các lập trình viên là một phần của một nhóm đáng tin cậy cốt lõi hoặc một số nhóm ngoài khơi?
• Quy mô của dữ liệu được truy vấn về hiệu suất ảnh hưởng là gì?
• Quy mô của dự án hoặc đô la liên quan là gì?
• Làm thế nào quan trọng là thời gian hoạt động?

Đô la nhỏ hơn cần ít quá trình hơn cần dòng phát triển nhanh hơn.

Đô la lớn hơn cần nhiều quá trình hơn cần các tiêu chuẩn nghiêm ngặt hơn về thực tiễn phát triển.

Thích ứng thực hành của bạn với những gì bạn đang làm.

Tôi làm việc như một nhà phát triển cho một công ty rất lớn. Tất cả các nhà phát triển của chúng tôi sẽ thực hiện bất kỳ loại hỗ trợ nào (về cơ bản là tất cả trong số họ) có quyền truy cập vào cơ sở dữ liệu sản xuất có liên quan. Tôi chỉ có thể nói cho nhóm cụ thể của mình, nhưng tôi sẽ cho bạn biết lý do tại sao chúng tôi có quyền truy cập.

1. Chúng tôi cần truy cập thời gian thực để theo dõi quá trình xử lý hàng ngày của chúng tôi. (Mặc dù chúng tôi có bảng điều khiển, chúng tôi cần có thể theo dõi sâu về mọi thứ. Mặc dù thật tuyệt khi có tính năng này trên bảng điều khiển của chúng tôi, chúng tôi thấy điều đó là không thực tế.)
2. Chúng tôi cần truy cập thời gian thực để điều tra bất kỳ lỗi sản xuất nào vì sự chậm trễ có thể có tác động rất lớn. (Tôi sẽ không thảo luận về những thất bại của chúng tôi ở đây. Chúng có đủ loại)
3. Chúng tôi thường cần làm báo cáo tùy chỉnh cho người dùng doanh nghiệp và thông tin này cần được cập nhật. (dba không có thời gian để làm điều này và chúng tôi không có thời gian để chờ đợi họ. Dù vậy, không lý tưởng, chắc chắn.)
4. Chúng tôi cần xác minh các triển khai / bản vá DDL / DML sản xuất. (Các DBA triển khai chúng, nhưng chỉ chúng tôi biết nên cấu trúc nó như thế nào. Chúng tôi biết nhiều hơn về cấu trúc cơ sở dữ liệu của chúng tôi so với các DBA. Chúng tôi có thể lạ ở đây, nhưng cơ sở dữ liệu rất phức tạp vì hoạt động kinh doanh của chúng tôi rất phức tạp.)

Hiệu suất là một mối quan tâm. Chúng tôi có sự xuất hiện của các nhà phát triển gây ra sự chậm lại. Tuy nhiên, đây là những trường hợp riêng biệt và SQL của chúng tôi được điều khiển hiệu năng đến mức hiếm khi các nhà phát triển của chúng tôi không hiểu tác động của các truy vấn của họ.

Đối với câu hỏi này, người ta phải cho rằng họ hiện không có quyền truy cập. Nếu tổ chức của một người đang phát triển phần mềm và điều này là để khắc phục sự cố của khách hàng và khách hàng cung cấp một bản sao cơ sở dữ liệu của họ, thì 'có'. Nếu không, tôi sẽ ủng hộ việc giữ các nhà phát triển ra khỏi sản xuất và có các môi trường thay thế được tạo ra cho nhu cầu nghiên cứu của họ. Một khi kem đánh răng đã ra khỏi ống, thật khó để đặt nó trở lại.

Tôi đồng ý rằng gánh nặng của sự biện minh nên thuộc về những người cần truy cập. Thông thường trong các môi trường mà tôi đã tham khảo ý kiến, tôi đã có quyền truy cập vào các hệ thống sản xuất nơi đó là một môi trường nhỏ và tôi là người hỗ trợ. Tôi đã có quyền truy cập vào các bản sao lưu, v.v. nơi tôi đã hỗ trợ cho hỗ trợ và truy cập gián tiếp (thông qua một nhà phát triển hỗ trợ chuyên dụng) vào dữ liệu sản xuất.

Vấn đề lớn là: Bạn cần quyền truy cập này khi bạn gặp khó khăn để giữ mọi thứ hoạt động trơn tru và bạn phải trả lời câu hỏi của anh chàng tài chính về điều gì đó không hoạt động. Bạn không thể luôn làm việc từ dữ liệu cũ cả ngày trong trường hợp đó. Mặt khác, càng truy cập nhiều thì nó càng tệ. Thông thường với tư cách là một nhà tư vấn, tôi có xu hướng tránh nhận loại quyền truy cập này trừ khi cần thiết. Vì tôi đang làm việc trên cơ sở dữ liệu tài chính, điều cuối cùng tôi muốn là bị buộc tội nhập hóa đơn của chính mình :-D.

Mặt khác, nếu bạn không cần quyền truy cập, bạn không nên có nó. Tôi thực sự không mua đối số dữ liệu nhạy cảm vì nhà phát triển có thể gặp khó khăn để đảm bảo rằng điều này được xử lý chính xác (và rất khó để xác minh mà không nhìn vào những gì thực sự được lưu trữ khi có báo cáo lỗi). Nếu bạn không thể tin tưởng nhà phát triển xem dữ liệu mà ứng dụng của nhà phát triển đang lưu trữ, bạn không nên thuê nhà phát triển viết ứng dụng. Có quá nhiều cách mà nhà phát triển có thể làm xáo trộn dữ liệu và gửi email đi và bạn không bao giờ có thể chắc chắn. Điều khiển MAC giúp ở đây nhưng chúng vẫn khá phức tạp để thực hiện.

Vấn đề lớn từ phía tôi phải làm với quyền truy cập ghi. Nếu một nhà phát triển không có quyền truy cập thì fortiori, nhà phát triển không có quyền truy cập ghi. Nếu bạn muốn xác minh tính toàn vẹn của sách, bạn muốn tiếp tục viết quyền truy cập vào càng ít người càng tốt. Đường mòn kiểm toán dễ dàng xác nhận hơn nhiều nếu các nhà phát triển không có quyền truy cập. Nếu nhà phát triển có quyền truy cập đọc, thì bạn luôn có một số câu hỏi là liệu đã có một tệp đính kèm đặc quyền nào đó có thể cung cấp quyền truy cập ghi (có thể là SQL tiêm trong thủ tục lưu trữ không?). Tôi thường có quyền truy cập đầy đủ vào thông tin thanh toán của khách hàng khi tôi có quyền truy cập vào môi trường dàn dựng. Nếu có một môi trường dàn dựng hoạt động mặc dù, tôi thường sẽ chủ động yêu cầu không có quyền truy cập vào sản xuất trừ khi nó là cần thiết.

Vì vậy, điều này là không hoàn hảo, tất nhiên. Một nhà phát triển vẫn có thể xây dựng các cửa sau vào ứng dụng có thể không phát hiện được, nhưng cách tiếp cận này là một cách tiếp cận hợp lý, thực tế là dữ liệu sao lưu có sẵn từ một ngày trước đó đối với tôi rằng đây là mối quan tâm của họ.

Hi vọng điêu nay co ich.

Chỉnh sửa: Chỉ cần thêm rằng trên các môi trường lớn hơn mà tôi đã làm việc, tôi đã có quyền truy cập vào dữ liệu sao lưu đầy đủ thường từ vài ngày tuổi đến vài tháng tuổi cho hệ thống tài chính. Điều này luôn đủ tốt cho công việc của tôi và lần duy nhất nó bị hỏng là khi các nhân viên tài chính cần một khả năng kiểm tra dữ liệu mới hơn để họ có thể phù hợp với sản xuất.

Không có quyền truy cập là một điều tốt và là cách để bảo vệ các nhà phát triển và những người khác không vô tình làm hỏng dữ liệu hoặc xem nó. Điều này cũng bảo vệ các công ty khỏi vi phạm pháp luật (tức là vi phạm Hipaa và các vấn đề riêng tư)

Một nhà phát triển không bao giờ thực sự cần truy cập vào một môi trường sản xuất, nó chỉ dễ dàng hơn từ quan điểm của các nhà phát triển nếu một lỗi khó có thể được sao chép.

Tuy nhiên, nhà phát triển có thể đặt các tệp nhỏ hoặc tệp nhật ký và sử dụng tệp ký hiệu PDB để tạo lại lỗi.

Nếu dữ liệu cần phải được đưa xuống môi trường thử nghiệm thì đó là điển hình cho một loại quy trình để xóa dữ liệu có thể tạo thêm công việc.

Tùy thuộc vào phần mềm cơ sở dữ liệu được sử dụng trong những gì bạn gọi là sản xuất, giấy phép mới có thể được yêu cầu cho nhà phát triển truy cập cơ sở dữ liệu, đây là một chi phí lớn để có quyền truy cập đọc.

Nếu công ty của bạn không cung cấp cho bạn các công cụ để gỡ lỗi hoặc nghiên cứu các vấn đề sản xuất thì đó không phải là vì bạn không có quyền truy cập vào dữ liệu sản xuất.

Dữ liệu là phần có giá trị nhất của hầu hết các ứng dụng!

Hiệu suất có thể là một trong những lý do.

Các truy vấn của nhà phát triển thường có thể không hiệu quả, gây ra tình trạng khóa hoặc sử dụng tài nguyên quá mức cho đến khi chúng được điều chỉnh đúng.

Một hệ thống sản xuất không phải là nơi thích hợp để các nhà phát triển thử nghiệm.

Nó phụ thuộc vào DBA và cách anh ấy hoặc cô ấy tự tin với nhà phát triển. Thông thường các nhà phát triển được cấp đặc quyền truy vấn (đọc) cho cơ sở dữ liệu sản xuất. Theo nguyên tắc thông thường, các nhà phát triển chỉ nên làm việc với cơ sở dữ liệu test / dev.

Thách thức là hầu hết các ứng dụng phần mềm đều được điều khiển dữ liệu. Vì vậy, khi bạn đang cố gắng khắc phục sự cố trong ứng dụng, bạn thực sự cần phải xem dữ liệu đang điều khiển nó. Vì vậy, các nhà phát triển thực sự cần một số hình thức truy cập.

Sử dụng thông tin đăng nhập SQL để chỉ cung cấp cho họ quyền truy cập chỉ đọc vào bảng là điều tuyệt vời. NHƯNG, điều gì ngăn họ tạo một truy vấn với 20 lần tham gia hoặc thực hiện CHỌN * từ một bảng có hàng triệu bản ghi? Các truy vấn này có thể vô tình giết chết hiệu suất của cơ sở dữ liệu và lưu trữ của bạn.

Công ty Stackify của tôi đã đưa ra một cách thông minh để giải quyết điều này. Các nhà phát triển có thể chạy truy vấn thông qua phần mềm của chúng tôi và chúng tôi sử dụng kế hoạch truy vấn để đảm bảo đó chỉ là một câu lệnh CHỌN và chi phí ước tính của truy vấn thấp và nó sẽ trả về chỉ một vài bản ghi. Bằng cách này, họ không thể làm hại nhiều. Chúng tôi cũng kiểm toán tất cả các truy vấn họ chạy.

Đây chỉ là một trong những điều chúng tôi cung cấp. Hãy xem chúng tôi tại http://www.Stackify.com để tìm hiểu thêm về các giải pháp hỗ trợ DevOps của chúng tôi .

Đúng. Trong một số trường hợp, sẽ hợp lý khi cho phép một số tập hợp con của người dùng, bao gồm cả nhà phát triển một số mức truy cập vào dữ liệu sản xuất truy vấn. Tuy nhiên, những hạn chế thích hợp phải được đặt ra vì hai lý do. Đầu tiên, là một DBA, bạn phải cố gắng hết sức để đảm bảo mức độ dịch vụ cần thiết cho tất cả người dùng. Ngoài ra, bạn muốn ngăn chặn các truy vấn xấu không chủ ý như xóa hàng loạt hoặc vi phạm các quy tắc kinh doanh. Nó nên đi mà không nói rằng phải có các biện pháp kiểm soát an ninh thích hợp.

Dù lý do bạn có thể không cho phép truy vấn ad hoc trực tiếp vào các bảng cơ sở dữ liệu, có thể có trường hợp được thực hiện để cho phép truy vấn để xem và các thủ tục được lưu trữ. Sử dụng quyền cơ sở dữ liệu, bạn có thể ngăn các truy vấn CHỌN trực tiếp các bảng và thậm chí giới hạn các chế độ xem và quy trình được lưu trữ mà người dùng nhất định có quyền truy cập. Phương pháp này không chỉ mang lại sự linh hoạt cho cơ sở người dùng của bạn, nó còn bảo vệ tính toàn vẹn và tính thực tế của dữ liệu của bạn khi được triển khai chính xác.

Trong công ty của chúng tôi, chúng tôi duy trì các nô lệ chỉ đọc các cơ sở dữ liệu sản xuất không dựa vào các dịch vụ sản xuất. Chúng tôi cấp cho các nhà phát triển quyền truy cập vào những người để truy cập vào dữ liệu sản xuất. Nếu có dữ liệu nhạy cảm (Thông tin khách hàng, thông tin thanh toán, v.v.), chúng tôi hạn chế sao chép các bảng đó và duy trì bảng dữ liệu mẫu trên máy chủ nô lệ.

Không bao giờ!!

Đây là lý do tại sao chúng tôi có máy chủ phát triển / Test / UAT. Dữ liệu từ Sản xuất có thể được sao chép vào môi trường thử nghiệm và các nhà phát triển có thể tiếp tục với thử nghiệm của họ. Chọn truy vấn có thể rất có hại trong trường hợp môi trường sản xuất. Nó làm tăng tải và vào thời gian cao điểm có thể làm giảm toàn bộ hiệu suất.

Mọi thông tin họ cần phải thông qua DBA, người có thể chạy những gì họ muốn (Chọn) và gửi cho họ kết quả. Đó là cách chúng ta làm trong môi trường của chúng ta.

Tôi không chắc tại sao mọi người cho rằng các nhà phát triển là ngu ngốc và không biết gì. Tôi nhận được một mẫu của rất nhiều vai trò khác nhau khi chúng bị rối tung và không nên "sản xuất". Tôi đã có các DBA, Quản trị viên Sys, Quản trị viên Mạng, Nhà phát triển, v.v ... tất cả đều gây rối.

Không ai (dev, dba, sa) có quyền truy cập vào bất kỳ máy chủ hoặc cơ sở dữ liệu nào trong bất kỳ môi trường nào có đăng nhập mạng bình thường. Tất cả đều có tài khoản "quản trị" cụ thể phải được sử dụng. Vâng, điển hình là dba và sa đang sử dụng chúng thường xuyên hơn, nhưng thậm chí họ nên bước đi nhẹ nhàng. Tôi đã bị đốt cháy bởi tất cả mọi người.

Vì vậy, vào một ngày tốt, không có vai trò CNTT nào cần truy cập. Tuy nhiên, sh! T đánh vào người hâm mộ, tất cả đều trên tay và chúng tôi cần đúng người giải quyết vấn đề. Điều này thường được dẫn dắt bởi nhà phát triển biết ứng dụng và hướng dẫn dba và sa đến một số điểm nhất định. Đó chỉ là sự chậm trễ không cần thiết hoặc yêu cầu và phê duyệt.

Ngoài ra, phê duyệt không bao giờ được theo sau bởi bất kỳ loại kiểm toán nào, vì vậy phê duyệt có nghĩa là không có gì.