Tại sao quản trị cơ sở dữ liệu rất khó?

Tôi biết rất nhiều Quản trị viên Cơ sở dữ liệu và họ đều trên 28-29 tuổi.

Là tất cả quản trị cơ sở dữ liệu như vậy? Ý tôi là, đây có phải là về trải nghiệm nhiều hơn ít nhất 7-8 năm không?

Hoặc là một quản trị viên cơ sở dữ liệu rất khó?

Vị trí này đòi hỏi một kiến ​​thức rộng, từ phát triển đến quản trị hệ thống và thậm chí là quản lý. DBA không chỉ phải biết về sao lưu, phục hồi, hoạt động nội bộ, bộ nhớ và bảo mật mà còn cả cách giao tiếp với cả nhà phát triển và quản lý. Một DBA có thể đưa ra một bản trình bày cấp cao cho ban quản lý, giúp nhà phát triển điều chỉnh truy vấn, cung cấp không gian đĩa cho một hệ thống mới và khôi phục dữ liệu từ bản sao lưu trong cùng một giờ. Những trách nhiệm này đòi hỏi rất nhiều kiến ​​thức với ít sự chồng chéo.

Hậu quả của sự thất bại thường lớn hơn đối với một DBA so với một nhà phát triển. Các DBA thường hỗ trợ hàng chục, thậm chí hàng trăm ứng dụng và hệ thống khác nhau, hầu hết trong số đó là yếu tố sống còn cho sự thành công của công ty. Một vi phạm bảo mật, lỗi khôi phục hoặc vấn đề về hiệu suất có thể đã ảnh hưởng sâu rộng và tàn phá. Điều này đòi hỏi một mức độ kiến ​​thức và kinh nghiệm không thể đạt được trong một khoảng thời gian ngắn.

DBA càng làm tốt công việc của họ thì khả năng hiển thị càng ít. Một DBA với cơ sở dữ liệu an toàn, có thể phục hồi, có sẵn và hoạt động tốt sẽ thiếu sự công nhận. DBA được chú ý khi có vấn đề. Họ không chỉ được chú ý khi các vấn đề của họ tự gây ra, họ còn bị đổ lỗi khi cơ sở dữ liệu có vấn đề do mã hóa kém, thiết lập mạng không đúng hoặc lưu trữ được cấu hình không chính xác.

Tôi đã chuyển từ nhà phát triển sang DBA khi tôi 29. Đối với tôi, những điều khiến việc trở thành một DBA trở nên khó khăn cũng khiến nó trở nên bổ ích. Tôi thích tiếp thu và sử dụng phổ kiến ​​thức rộng, và cơ hội thất bại lớn hơn khiến cho việc tránh chúng trở nên có ý nghĩa hơn cho dù người khác có thấy điều đó hay không.

Trở thành một DBA thực sự đòi hỏi một kinh nghiệm tuyệt vời nhưng về cơ bản nó chỉ có thể đến từ bốn con đường khác nhau:

1. Là một nhà phát triển và tạo ra sự khác biệt với DBA
2. Là một nhà phát triển và được soạn thảo như một DBA
3. Đào tạo trực tiếp từ trường cao đẳng / thương mại để trở thành một DBA
4. Trở thành một SysAdmin và tạo ra sự khác biệt hoặc thực hiện nhiệm vụ kép như một DBA

Là một nhà phát triển và tạo ra sự khác biệt cho một DBA

Trong một câu hỏi khác được hỏi trên trang này, Làm thế nào các DBA có thể 'thân thiện với lập trình viên' hơn , tôi đã đề cập rằng tôi là một nhà phát triển trong 16 năm làm việc với các DBA. Làm việc với họ khiến tôi nhận ra rằng ở mức độ kinh nghiệm của họ bao gồm lý thuyết cơ sở dữ liệu, toán học rời rạc và kinh nghiệm lập trình, đến mức họ có thể thấy cơ sở dữ liệu nên hoạt động như thế nào và cách truy vấn nên thực thi.

Có một DBA với những điều đó trong nền tảng của họ làm cho tôi cảm thấy tôi vẫn đang học đại học từ một giáo sư phụ trợ nhưng người thực sự biết công cụ của họ. Miễn là DBA sẵn sàng chia sẻ những gì họ biết, mà không cần phải nói điều đó với bạn , họ thực sự có thể trở thành cố vấn của bạn về mặt phát triển các câu lệnh SQL (bản thân SQL là Ngôn ngữ lập trình nhạy cảm theo ngữ cảnh) hiệu quả như khả thi. Chắc chắn, có những phần trần tục khác, chẳng hạn như thực hiện cài đặt, tạo bản sao lưu, thực hiện nâng cấp phần mềm, theo dõi số liệu hiệu suất, tạo báo cáo, v.v. Nhưng với tư cách là một nhà phát triển, nếu bạn tập trung vào cơ sở dữ liệu và SQL chạy với các cơ sở dữ liệu đó, theo thời gian, bạn sẽ trở nên thành thạo về SQL đến nỗi nó sẽ là bản chất thứ hai và bạn có thể tập trung vào phát triển ứng dụng.

Các yêu cầu đối với một nhà phát triển có thể bị đánh thuế, nhưng DBA cũng vậy. Nhà phát triển tự nguyện chuyển sang vai trò của một DBA chuyển trọng tâm từ phát triển và mã hóa sang những thứ trần tục mà tôi đã đề cập trước đây. Trước điều này, DBA phối hợp chặt chẽ với các lập trình viên tạo cơ hội cho DBA đóng góp sáng tạo cho bất kỳ dự án nào, do đó làm cho vai trò của một DBA trở nên thú vị hơn nhiều.

Là một nhà phát triển và được soạn thảo như một DBA

Đối với hầu hết các nhà phát triển không thấy gì ngoài việc phát triển và mã hóa cho đến hết đời, điều này có thể giống như chọn trở thành trong chương trình thực tế Survivor hoặc chương trình trò chơi Wipeout . DBA mới dành thời gian của họ để tương tác với Hộp đen đó (được biết đến với tất cả chúng ta đơn giản là cơ sở dữ liệu) mà họ đã liên hệ để lấy dữ liệu trong nhiều năm qua.

DBA mới hiện có thể tạo các bảng và chỉ mục của riêng họ. Điều này có thể giống như để một Hibachi Nhật Bản nấu ăn trong một nhà hàng Ý. Đầu bếp có thể đánh bất cứ thứ gì, nhưng phải nhận ra rằng có những công thức mới, dụng cụ nhà bếp, dao kéo, thịt, gia vị, rau củ, và nhiều thứ trần tục khác để điều chỉnh (vệ sinh, kiểm kê, thời gian bắt đầu, giờ làm việc, v.v.). Đây không chỉ là thời gian chuyển tiếp mà còn là thời gian để vượt qua một đường cong học tập tuyệt vời. Một cấp độ kinh nghiệm mới phải được học và phát triển mặc dù chuyên gia nấu ăn Nhật Bản trong những năm qua. Trong khía cạnh này, các Nhà phát triển phải tự điều chỉnh lại để suy nghĩ như một DBA.

Đào tạo trực tiếp từ trường đại học / thương mại để trở thành một DBA

Đây là cách nguy hiểm nhất để trở thành một DBA. Đây cũng là con đường hiếm hoi nhất trên thực tế, điều này hầu như chưa từng nghe thấy. Bây giờ chúng tôi đang nói chuyện cho phép ai đó từ McDonald hoặc Burger King vào cùng một nhà hàng Ý.

Ba đường cong học tập có liên quan:

1. Áp dụng các kỹ năng từ trường đại học / thương mại vào vai trò DBA,
2. Tương tác với RDBMS cụ thể (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres) và,
3. Tương tác với các Nhà phát triển ( một DBA tương lai học các kỹ năng xã hội đàng hoàng ngay khi ra trường? Phải, phải không! ).

Trong đó, các nhà phát triển sẽ có ưu thế hơn các DBA trong nhiều năm. Các DBA phải học cách điều chỉnh nhanh chóng theo nhu cầu của các nhà phát triển trong những năm đầu làm DBA. Có lẽ một DBA có thể kiếm được một mức lương khởi điểm khá, nhưng khó phát triển hơn nếu không phát triển bản thân trong ba lĩnh vực học tập này.

Trở thành một SysAdmin và thực hiện một nhiệm vụ hoặc tăng gấp đôi nhiệm vụ như một DBA

Là một nhà phát triển trước đây và bây giờ là một DBA, một điều không được coi là đương nhiên là vai trò của SysAdmin.

Có vai trò của SysAdmin / DBA là một chút cảm hứng đối với tôi. Tại công ty lưu trữ của chủ nhân của tôi, chúng tôi có một anh chàng là SysAdmin / DBA (SCMDBA). Anh ta quá mải mê với các dự án cơ sở hạ tầng cộng với các hợp đồng MySQL nội bộ của riêng anh ta. Tôi không ghen tị với anh ta, tôi khen ngợi anh ta. Thành thật mà nói, vì tâm trí thực sự của SysAdmin / DBA là xa lạ với tôi, tôi để nó theo ý của SysAdmin / DBA để cập nhật đoạn này (hoặc thay thế hoàn toàn) để mô tả đường dẫn này .

Phần kết luận

Bất kể bạn chọn con đường nào, vai trò của một DBA có thể được phân biệt hoặc kinh tởm, tùy thuộc vào mức độ bạn sẵn sàng được cố vấn (hoặc bị tra tấn) ngay từ đầu và bạn sẵn sàng làm việc với thời gian khác như thế nào. Chỉ sau đó, người ta có thể nói họ thích làm DBA.

Nhân tiện, thật tình cờ tôi đã trải nghiệm hai con đường DBA đầu tiên bắt đầu từ tháng 8 năm 2004 ở tuổi 39. Hai năm kinh nghiệm tôi có trong vai trò DBA được phác thảo khiến việc chuyển sang một DBA toàn thời gian rất thú vị và thoải mái .

Lời khuyên của tôi cho các DBA 28-29 tuổi? Làm việc tốt với mọi người như bạn với RDBMS. Nếu bạn phát triển trong cả hai lĩnh vực, bạn có thể biến nó thành một DBA trong nhiều năm tới.

Quản trị cơ sở dữ liệu khó khăn vì hai lý do

Phản hồi chậm Nếu một người đưa ra một quyết định tồi trong vai trò của một kiến ​​trúc sư phần mềm, thường sẽ mất nhiều thời gian hơn để nhận được phản hồi tiêu cực so với một lập trình viên. Lập trình viên thường có thể nhận ra lỗi trong quá trình biên dịch hoặc trong khi chạy kiểm tra, điều đó có nghĩa là chu trình học khá nhanh. Quản trị viên cơ sở dữ liệu mắc lỗi trong khi thiết kế cơ sở dữ liệu có thể chỉ nhận được phản hồi khi anh ấy / cô ấy phát hiện ra người dùng cuối sẽ thực sự sử dụng phần mềm như thế nào. Điều này có nghĩa là có thể mất nhiều năm để có được phản hồi rằng thiết kế cơ sở dữ liệu bị thiếu sót và cần phải được làm lại. Do đó, phải mất nhiều năm để có được kinh nghiệm, thay vì vài phút (đôi khi) cho các lập trình viên.

Những sai lầm đắt giá Đây cũng là lý do tại sao các CEO của các công ty lớn thường ở độ tuổi 50.

Nó là khá dễ dàng để trở thành một DBA xấu

Nghiêm túc mà nói, một DBA thường có trách nhiệm đặc biệt đối với một thứ thường rất quan trọng đối với sự thành công hay thất bại của một doanh nghiệp: dữ liệu của nó

Nếu bạn điều hành một công ty thì bạn có thể muốn tuyển dụng những người có kinh nghiệm có năng lực trong vai trò đó

Tôi không nghĩ đó là một câu hỏi về 'dễ dàng hơn' hay 'khó khăn hơn' - chỉ là một câu hỏi về việc dữ liệu của bạn có giá trị như thế nào: Không khó để đặt một vệ tinh trong không gian hơn một người, nhưng bạn sẽ kiểm tra số tiền của mình một thỏa thuận tốt hơn cho sau này

Theo tôi, trở thành Quản trị viên Cơ sở dữ liệu thật dễ dàng ... cho đến khi một cái gì đó phá vỡ mối đe dọa của công ty và gánh nặng sửa chữa và khôi phục bất cứ điều gì nó đang ở trên vai bạn.

Trở thành Quản trị viên Cơ sở dữ liệu (hoặc Quản trị viên Mạng hoặc Hệ thống) là một vị trí yêu cầu một mức trưởng thành nhất định. Nó cần một người làm việc tốt dưới áp lực. Điều đó không có nghĩa là không có những người trẻ tuổi ngoài kia có thể xử lý việc này với các kỹ năng cần thiết.

Ngoài ra, thật dễ dàng để tìm hiểu các lệnh từ một cuốn sách để sao lưu / khôi phục cơ sở dữ liệu, tối ưu hóa cấu hình máy chủ, v.v. Nhưng kinh nghiệm sẽ chiến thắng khi bạn nhận được cảnh báo rằng cơ sở dữ liệu của bạn bị hỏng.

Tôi biết rất nhiều Quản trị viên Cơ sở dữ liệu và tất cả họ đều trên 28-29 tuổi. Là tất cả quản trị cơ sở dữ liệu như vậy?

Hầu hết các lập trình viên giỏi, giỏi mà tôi biết cũng ít nhất 25 tuổi. Tôi tưởng tượng có một yếu tố tương quan với tuổi + kinh nghiệm = lập trình viên giỏi. ;)

Ý tôi là, đây có phải là về trải nghiệm nhiều hơn ít nhất 7-8 năm không? Hoặc là một quản trị viên cơ sở dữ liệu rất khó? Bạn nghĩ sao?

Trở thành một quản trị viên cơ sở dữ liệu không dễ dàng, nếu đó là điều bạn muốn nói. Có rất nhiều điều mà bạn nên biết khi là một dba. Điều đó cũng có nghĩa là trường học, và nó có nghĩa là một vài năm dạy kèm dưới một người khác. Hãy nhớ rằng cơ sở dữ liệu là logic tập hợp, mà hầu như không ai đi học đủ lâu để học, do đó không ai biết về nó. Set-logic chia sẻ một số quy tắc với đại số, nhưng các công cụ (MSSQL, Oracle, v.v.) chính là những con thú xoắn của việc thực hiện các quy tắc đó, vì vậy bạn không chỉ phải hiểu toán học đằng sau cơ sở dữ liệu, bạn còn phải hiểu cách thực hiện mà bạn chạy trên đỉnh. Điều đó thậm chí không được tính khi biết ngôn ngữ kịch bản ưa thích của bạn (PL / SQL, TSQL, v.v.).

Sau đó, xem xét rằng là một dba, bạn sẽ chịu trách nhiệm đảm bảo rằng dữ liệu kinh doanh quan trọng nhất sẽ thường được giao cho bạn. Bạn cần phải vượt qua những phần tồi tệ nhất của "phạm sai lầm ngớ ngẩn" và bạn cần phải học được một chút tự kiềm chế. Hầu hết mọi người ở 21-23 chưa học được điều đó. Một số người trong chúng ta ở tuổi 30 vẫn chưa có.

OT: Đây là lý do tại sao tôi nói rằng mọi người không thực sự biết bất cứ điều gì cho đến khi họ ít nhất 40 tuổi và sau đó họ được xem xét trên ngọn đồi, trong khi thực tế họ chỉ đạt được bước tiến của họ. (nói như một người 31 tuổi)

Tôi không nghĩ rằng trở thành một DBA là khó. Trở thành một mặc dù.

Tôi muốn trả lời để thêm một khía cạnh khác không được thảo luận ở trên: lĩnh vực tầm nhìn.

Có rất nhiều vai trò cho các nhà phát triển và một số (ví dụ: phát triển trình điều khiển thiết bị hoặc phát triển lịch trình hệ điều hành) đòi hỏi một tầm nhìn rất hẹp và khả năng đào sâu vào một vấn đề nhỏ và nhìn từ góc độ kỹ thuật thuần túy . Có những lĩnh vực khác đòi hỏi tầm nhìn rất rộng nhưng không có nhiều chiều sâu kỹ thuật (phát triển ứng dụng kinh doanh với khung ERP bạn chọn).

Cơ sở dữ liệu là duy nhất bởi vì để làm tốt chúng, bạn phải có khả năng di chuyển giữa các chế độ này một cách nhanh chóng và liền mạch. Cơ sở dữ liệu là các công cụ toán học nhưng chúng là các công cụ toán học phù hợp với môi trường kinh doanh theo những cách rất phức tạp. Do đó, người ta phải có khả năng giải quyết vấn đề toán học như một vấn đề toán học và cũng hỏi làm thế nào nó phù hợp với mọi thứ khác.

Khi bạn nhìn vào các kỹ sư mạng cao cấp hoặc quản trị viên hệ thống cao cấp, họ là đối thủ gần nhất với một DBA cao cấp trong lĩnh vực này (mặc dù mỗi lĩnh vực khá khác nhau - một sysadmin cao cấp đòi hỏi tầm nhìn rộng hơn cả một dba tốt, và kỹ sư mạng tốt đòi hỏi một lĩnh vực sâu hơn).

Nói cách khác, để trở thành một DBA giỏi, bạn cần có khả năng di chuyển giữa các yêu cầu kinh doanh cấp cao và hiểu biết ở mức độ thấp liên quan đến lưu trữ trên đĩa thực tế, và qua các vấn đề kỹ thuật quan hệ và thuần túy về thiết kế, hoàn toàn không có bất kỳ sự chuyển đổi thực sự nào (và có lẽ trong quá trình đánh giá một quyết định cụ thể).

Tôi hoạt động như một DBA và một nhà phát triển. Hai vai trò cực kỳ bổ sung, nhưng tôi là một DBA đầu tiên và nếu bạn thấy các thư viện tôi đã viết, điều đó là hiển nhiên. Nhưng lý do chúng bổ sung là vì ở khía cạnh phát triển, tôi có thể giao tiếp trực tiếp với người dùng cuối của phần mềm và vì vậy tôi liên tục bị thúc đẩy về tầm nhìn của mình, trong khi về phía db tôi phải thử thách bản thân về độ sâu.

Có một con đường khác, hơi khác so với những cái được liệt kê.

Bắt đầu như một nhà phát triển, sau đó trở thành một nhà thiết kế cơ sở dữ liệu, sau đó trở thành một DBA. Con đường này phổ biến hơn khoảng ba mươi năm trước, khi cơ sở dữ liệu bắt đầu vượt qua các ứng dụng dựa trên tệp thời gian lớn và những người có chuyên môn về cơ sở dữ liệu rất ít

PS: Khi tôi là một lập trình viên cũ chuyển sang DBA, các lập trình viên thường hỏi tôi "không phải DBA làm việc nhàm chán sao?"

Câu trả lời của tôi: "nó chỉ nhàm chán khi bạn làm đúng!". :)

Tôi khá là bắt đầu hành trình DBA của mình, nhưng đây là một vài lý do khiến mọi người có thể thấy công việc này khó khăn ... Thật khó vì:

• bạn có rất nhiều trách nhiệm: mọi người có thể đến và đi trong một công ty, nhưng đối với khá nhiều người trong số họ, tài sản quan trọng nhất của họ là dữ liệu của họ. Bạn chịu trách nhiệm cho nó và có tất cả quyền hạn đối với nó. Như đã nói, với sức mạnh lớn đến trách nhiệm lớn. Những sai lầm rất tốn kém đang rình rập xung quanh.
• bạn phải học và tiếp tục học hỏi: Tôi thấy đây là một phần thưởng, nhưng không phải tất cả mọi người đều sẵn sàng dành thời gian để cập nhật kiến ​​thức của họ.
• nó có thể tốn thời gian: mọi thứ sẽ tan vỡ vào giữa đêm, bạn sẽ sẵn sàng chứ?
• bạn thường sẽ phải sửa chữa những sai lầm của người khác: và bạn hầu như sẽ không nhận được nhiều tín dụng cho tất cả công việc tốt của mình. Đừng sợ để nâng cao kỹ năng con người của bạn.

Brad Mc Gehee đã viết một cuốn sách về nó, "Làm thế nào để trở thành một DBA đặc biệt". Đáng đọc nếu bạn có ý định làm sâu sắc thêm câu hỏi.

Chúc may mắn!

Tôi đã trở thành một dba ở tuổi 25. Tôi mất 6 tháng kể từ khi tôi bắt đầu học để được chứng nhận và 2 tháng sau tôi có việc làm. Tôi nghĩ quyết tâm chắc chắn đóng một phần quan trọng. Đối với tôi nó không khó để có được công việc. Tất cả chỉ là sức mạnh ý chí để nghiên cứu và cho thấy rằng tôi có khả năng học hỏi những gì từng được đặt trước mặt tôi.

Tôi sẽ nói rằng tất cả những gì tôi có là bằng cấp tâm lý học và nền tảng bàn trợ giúp. Khi tôi nhận được công việc là một DBA của Oracle Apps, tôi đã nghĩ ngay đến OMG, tất cả những thứ tôi học để trở thành một DBA CORE không giúp tôi một chút nào. Tôi nhớ cảm giác vô cùng choáng ngợp. Tôi đã phải tự nhắc nhở mình hàng ngày tôi có thể học được điều này và 2 năm sau tôi đã có được nhiều kiến ​​thức hơn.

Điều tôi đang nói là, trở thành một DBA không khó, không khó chút nào, nhưng học mọi thứ trong công việc và ngoài công việc, mà chúng ta nên biết như những dba trước đây đã đề cập trước đây rất tốn thời gian và cần nhiều sự chăm chỉ. Tôi đã tìm thấy ở 27 người hầu hết những người ở độ tuổi hoặc trẻ hơn của tôi không có sự siêng năng cũng như không muốn tìm hiểu một phổ công nghệ lớn như vậy. Nhưng tôi yêu công việc của mình với tư cách là một DBA của Oracle Apps và mong muốn mọi thứ khác sẽ liên tục bị ném theo cách của tôi để học. Bạn có thể làm điều đó, nếu bạn tập trung vào nó, không quan trọng bạn bao nhiêu tuổi!

Trở thành một DBA cũng có nghĩa là bạn chủ động thay vì phản ứng. Bạn phải có khả năng tưởng tượng những gì tương lai nắm giữ và lập kế hoạch phù hợp. Điều này liên quan đến việc làm việc chăm chỉ ... một lần, rất nhiều lần và nếu bạn làm đúng, phần thưởng hoàn toàn không được công nhận tên. :-) Bạn cũng phải có khả năng nói "không" với mọi người (bao gồm cả sếp) và khách quan, truyền đạt hiệu quả lý do của bạn tại sao về mặt khán giả của bạn có thể hiểu. Bạn phải thận trọng và đưa ra quyết định hợp lý trong các tình huống áp lực cao. Bạn phải có khả năng sở hữu những sai lầm của mình một cách nhanh chóng và không để chúng xuất hiện trên màn hình xanh mà thay vào đó, chuyển đổi hiệu quả các bánh răng từ "Tôi không thể tin rằng tôi vừa làm điều đó" thành "Được rồi, cách tốt nhất để khắc phục điều này".

Là một người tự coi mình là SysAdmin và thứ hai là một DBA tình cờ, tôi nghĩ rằng một phần của nó phụ thuộc vào lượng kiến ​​thức cần có để tự mình đứng lên và thực hiện công việc, hoặc có lẽ quan trọng hơn là hiểu công việc.

Tôi nghĩ rằng chứng nhận MCDBA cũ tổng hợp khá tốt. Nó yêu cầu bốn bài kiểm tra phải được thông qua, bài kiểm tra SysAdmin, bài kiểm tra Cơ sở hạ tầng mạng, bài kiểm tra Phát triển cơ sở dữ liệu và bài kiểm tra Quản trị SQL. Đó là một loạt các chủ đề, vì vậy thực tế bạn có thể đến với nó thông qua một trong số chúng trước tiên. Tôi sẽ lập luận rằng phần lớn Quản trị SQL đứng trên vai của ba người kia, vì vậy hầu hết mọi người đến đó thông qua một trong những tuyến đường ban đầu. Ví dụ, một SysAdmin xử lý các bản sao lưu SQL (bước đột phá đầu tiên của tôi vào SQL nhiều năm trước) hoặc Nhà phát triển thiết kế cơ sở dữ liệu cho mã mà họ đang viết. Bắt đầu, bạn sẽ không biết tất cả mọi thứ, nhưng bạn sẽ có cơ sở ít nhất là một phần của nó, ví dụ như hệ thống SQL chạy và cách thức hoạt động của quyền hoặc các phương pháp lập trình được sử dụng để nói chuyện với cơ sở dữ liệu,

Thật khó để đánh giá liệu trở thành một DBA có thực sự là điều bạn muốn làm cho đến khi bạn thực hiện nó hay không, nhưng thông qua lộ trình trên, mọi người có thể dần dần xây dựng nó. Bạn có thể yêu thích nó và làm cho nó trở thành trọng tâm nghề nghiệp của bạn, hoặc thấy nó không dành cho bạn và gắn bó với con đường sự nghiệp trước đây của bạn, tất cả mà không có một bước nhảy vọt vào ẩn số. Nhưng, điều đó cần có thời gian và điều đó phù hợp với xu hướng của DBA là "khôn ngoan hơn trong nhiều năm" trong ngành.

Để trở thành một DBA giỏi, bạn cũng cần sự tự tin và trưởng thành có xu hướng đi cùng với tuổi tác. Những người khác đã liệt kê các khía cạnh khác của vấn đề này, nhưng tôi thêm tự tin để nói không và giữ vững lập trường của bạn, tôi luyện với kinh nghiệm để biết khi nào thì phù hợp.

Cuối cùng, tôi nghĩ rằng để trở thành một DBA giỏi đòi hỏi một tư duy nhất định, và thật khó để biết liệu bạn có điều đó cho đến khi bạn ở trong chiến hào. Có một mắt để biết chi tiết, sẵn sàng lên kế hoạch trước, khả năng nhìn vào bức tranh lớn và không sợ ghi lại công việc của bạn là những khía cạnh quan trọng của việc duy trì một hệ thống ổn định. Một số SysAdmins và Nhà phát triển giống như vậy và có thể dễ dàng thực hiện chuyển đổi, trong khi những người khác có thể thấy rằng trong khi cách tiếp cận của họ có giá trị trong công việc hiện tại của họ, vì là một DBA, họ sẽ đấu tranh và tìm thấy những điều này là một việc vặt và không thích công việc.

Tôi nghĩ rằng phần khó khăn nhất của việc ít nhất trở thành một quản trị viên cơ sở dữ liệu không tự nguyện là thực tế là bạn phải chịu bất cứ điều gì xảy ra với cơ sở dữ liệu của tổ chức cụ thể mà bạn đã tình cờ gặp phải.

Theo kinh nghiệm của tôi, cú sốc đầu tiên của tôi là vào một buổi sáng thứ Hai khi máy chủ cơ sở dữ liệu bị sập vì một lỗi dường như là phần cứng, tuy nhiên tôi vẫn bị nghi ngờ là đã làm sai điều gì đó.

Bạn có thể tưởng tượng rằng bất cứ điều gì một người đã từng học hoặc thực hiện trong cuộc đời của họ phải được áp dụng để làm cho điều đó hoạt động trở lại. Sau đó, tất nhiên, bạn có thể tạo một bản sao và thậm chí flash sao lưu toàn bộ - chúng ta đang nói ở đây chỉ về một máy chủ cơ sở dữ liệu nhỏ định tuyến mọi thứ tới các mạng máy tính khác thông qua các máy chủ liên kết. Tuy nhiên, trách nhiệm cảm thấy rất lớn trong những khoảnh khắc.

Là một nhà phát triển phần mềm hoặc là một người kiểm thử phần mềm, trách nhiệm cũng rất lớn, nhưng tôi chưa bao giờ trải qua những thời điểm khó khăn như vậy. Tôi có thể tưởng tượng rằng lý do nằm ở chỗ mỗi người trong số họ chỉ dệt một chút mạng nhện của thế giới công nghệ thông tin.

Nếu tôi từng trở thành một quản trị viên cơ sở dữ liệu, tôi sẽ cập nhật bất cứ điều gì tôi đã viết bây giờ ở đây.

Và, vâng, tôi bây giờ 38 + 1/2 tuổi.

Giống như hầu hết các kỹ năng, học để trở thành một dba cần có thời gian. Trở thành một dba tốt mất nhiều thời gian hơn. Bạn càng đọc và tìm hiểu nhiều kiến ​​thức bạn có thể áp dụng.

Một con đường khác để trở thành một dba là viết báo cáo hoặc là một chuyên gia ứng dụng. Bạn càng dành nhiều thời gian với SQL, bạn sẽ càng học được nhiều hơn về cách hoạt động của dbs. Trở nên thành thạo các truy vấn SQL sẽ cung cấp một điểm khởi đầu tốt để trở thành một dba.