Good works, guys :)). Vậy, nói chung, các ý kiến ở đây đều tập trung ở hai khía cạnh: kinh nghiệm (experience) và kiến thức (knowledge). Thử xem ngoài 2 khía cạnh trên, các tiến trình xác định sự cố còn dùng những gì khác qua trường hợp cụ thể hơn như sau: "Hôm nay, ngày đầu tuần. Tuấn vào sở và không thể bật máy lên được. Có hai mươi lăm máy khác trong cùng phòng không bị sự cố này. Tuấn thử đổi ổ điện, đổi dây cắm điện nhưng vẫn không có gì khá hơn. Không thể xác định nguyên nhân khác, Tuấn đợi Tú (quản lý hệ thống) vào để hỏi thêm lý do. Khi Tú vào, Tuấn hỏi những câu sau: 1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?" Vậy trong đoạn trên, ngoài việc dùng kinh nghiệm (experience) và kiến thức (knowledge) chuyên môn (mà Tuấn không có đủ so với Tú), Tuấn đã thử dùng thêm những gì để định hướng sự cố? Mời anh chị em tiếp tục thảo luận :)). 

.... P/S : Nếu có thể thì hãy cho chủ đề này mở rộng sang phần: "kinh nghiệm xử lý tình huống đối với 1 admin hệ thống" luôn nhé bác conmale. Vì nó rất cần thiết cho những newbie mói7 bắt đầu mtap65 làm wen với quản trị hệ thống  

:)). Hầu hết mọi người có chiều hướng đi thẳng vào chuyện định bệnh và giải quyết sự cố. Thậm chí đi sâu vào chi tiết, nào là kiểm tra cái này, xem cái kia.... Bởi vì việc mở máy lên không được là việc khá dễ xác định nguyên nhân và đây là một trở ngại tương đối đơn giản nên ai đã từng vọc máy thì sẽ nhảy ngay đến biện pháp. Tuy nhiên, nếu vấn đề trở nên phức tạp hơn nhiều, có nhiều tầng, nhiều lớp, nhiều cá nhân liên quan đến sự cố... thì làm sao có thể nhảy đến biện pháp? Điểm cần bàn ở đây là một phương pháp định hướng (methodology) có lớp lang, có thứ tự và khoa học chớ không chỉ dựa vào kinh nghiệm cá nhân hoặc một số nhận định cảm tính. Cũng như mẩu chuyện ở trên, thay vì Tuấn hỏi Tú vài câu đơn giản, Tuấn gầm thét lên và bảo rằng, trong 15 phút nữa Tuấn sẽ có một cuộc họp cực kỳ quan trọng với khách hàng và trọn bộ thông tin nằm trên máy này, thì biên độ của sự cố hoàn toàn khác. Khi Tuấn nói: "1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?" Tuấn muốn dùng đến những gì bên ngoài kiến thức và kinh nghiệm để giúp Tú xác định sự cố? Nên đào sâu hướng này thay vì đi vào hướng "tháo ổ cứng ra, tháo ổ tiếp điện ra...." Còn quá sớm để đi thẳng vào những việc này. 

Tuấn wrote:

"1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không?  

Tớ thấy 2 câu hỏi này không có giá trị . 

Tuấn wrote:

"1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy?  

Từ đây ta có 2 trường hợp hành động của Tú , không phải là 2 trường hợp trả lời của Tú . Thứ nhất , nếu Tú không động vào máy làm việc của Tuấn , mà đây là điều rất có khả năng xảy ra , thì đương nhiên Tú sẽ trả lời là không . Còn nếu Tú đã táy máy vào máy của Tuấn thật , thì chia ra 2 khả năng là hành động đó hợp pháp và không hợp pháp . Nếu là hành động hợp pháp , tức là phải có thông báo từ trên , Tuấn đã phải được biết điều đó và không hỏi câu hỏi này . Còn nếu không hợp pháp thì blah blah blah .

Tuấn wrote:

2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không?  

Anh ta là người làm việc , anh ta chỉ có trách nhiệm thao tác với máy và không cần phải can thiệp sâu vào cấu trúc bên trong của máy . Thứ nữa , Tú cũng không phải cung cấp những thông tin này cho Tuấn . Sửa chữa là trách nhiệm của kỹ thuật viên . Nếu như anh ta biết được những thông tin này , và nhờ đó có thể giải quyết được . Thì tức là phải còn rất nhiều những điều kiện ngoại biên . Tóm lại là những câu hỏi này không có giá trị . 

Vừa hô đã có ngay điều kiện ngoại biên :

conmale wrote:

Nếu Tú đúng là kỹ thuật viên thì sao?  

Nếu có thêm điều kiện mới thì mọi việc phải xem xét lại từ đầu . 2 đầu bài khác hẳn nhau . Còn đoạn blah blah blah thì blah blah blah... Cháu sẽ sửa . Thân ! 

"Hôm nay, ngày đầu tuần. Tuấn vào sở và không thể bật máy lên được. Có hai mươi lăm máy khác trong cùng phòng không bị sự cố này. Tuấn thử đổi ổ điện, đổi dây cắm điện nhưng vẫn không có gì khá hơn. Không thể xác định nguyên nhân khác, Tuấn đợi Tú (quản lý hệ thống) vào để hỏi thêm lý do.  

Chết chết , blah blah blah ... một hồi trả lời loạn mất .

conmale wrote:

Nếu Tú đúng là kỹ thuật viên...  

Thì Tú đúng là kĩ thuật viên . Không phản đối . Quả đấy tưởng chú bảo "Tuấn" . Trở lại chỗ đấy nhé , Tú là kĩ thuật viên thì sao . Việc anh ta nắm thông tin , không ràng buộc anh ta phải cũng cấp thông tin cho bất kì ai . Hơn nữa , vì anh ta ( TÚ ) là kĩ thuật viên nên bảo mật thông tin là yếu tố quan trọng . Tóm lại là nói cho Tuấn biết mấy cái đó làm gì , người ta gọi là ... rách việc . 

conmale wrote:

Tuấn là sếp của Tú 

Lần này cháu đọc kĩ lắm rồi , Tuấn là sếp của Tú (!) ở chỗ nào thế ? 

Cũng như mẩu chuyện ở trên, thay vì Tuấn hỏi Tú vài câu đơn giản, Tuấn gầm thét lên và bảo rằng, trong 15 phút nữa Tuấn sẽ có một cuộc họp cực kỳ quan trọng với khách hàng và trọn bộ thông tin nằm trên máy này, thì biên độ của sự cố hoàn toàn khác.  

Vậy, nói chung, các ý kiến ở đây đều tập trung ở hai khía cạnh: kinh nghiệm (experience) và kiến thức (knowledge). Thử xem ngoài 2 khía cạnh trên, các tiến trình xác định sự cố còn dùng những gì khác qua trường hợp cụ thể hơn như sau: "Hôm nay, ngày đầu tuần. Tuấn vào sở và không thể bật máy lên được. Có hai mươi lăm máy khác trong cùng phòng không bị sự cố này. Tuấn thử đổi ổ điện, đổi dây cắm điện nhưng vẫn không có gì khá hơn. Không thể xác định nguyên nhân khác, Tuấn đợi Tú (quản lý hệ thống) vào để hỏi thêm lý do. Khi Tú vào, Tuấn hỏi những câu sau: 1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?"  

conmale wrote:

Vậy, nói chung, các ý kiến ở đây đều tập trung ở hai khía cạnh: kinh nghiệm (experience) và kiến thức (knowledge). Thử xem ngoài 2 khía cạnh trên, các tiến trình xác định sự cố còn dùng những gì khác qua trường hợp cụ thể hơn như sau: "Hôm nay, ngày đầu tuần. Tuấn vào sở và không thể bật máy lên được. Có hai mươi lăm máy khác trong cùng phòng không bị sự cố này. Tuấn thử đổi ổ điện, đổi dây cắm điện nhưng vẫn không có gì khá hơn. Không thể xác định nguyên nhân khác, Tuấn đợi Tú (quản lý hệ thống) vào để hỏi thêm lý do. Khi Tú vào, Tuấn hỏi những câu sau: 1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?"  

Hì , đây là 1 kiểu rất hay gặp khi xử lý sự cố: hỏi ý kiến chuyên gia. Tuấn là hình mẫu của 1 user , còn chuyên gia gần nhất, dễ hỏi nhất là người quản trị hệ thống đó: Tú. Vậy trong đoạn trên, ngoài việc dùng kinh nghiệm (experience) và kiến thức (knowledge) chuyên môn (mà Tuấn không có đủ so với Tú), Tuấn đã thử dùng thêm kinh nghiệm và kiến thức của người khác để định hướng sự cố, và "người khác" ở đây có kiến thức và kinh nghiệm có thể tạm tin tưởng.  

to conmale : cháu không bàn luận về vấn đề tâm lý con người . Rất có thể 2 người này đều trực thuộc sếp lớn . Một ông phòng kĩ thuật , còn một ông phòng nào đó quan trọng không biết . Nếu muốn giải quyết ngay ( 15 phút ) thì cần có lệnh từ trên , mọi lời nói lúc đó đều không có chứng cứ . Nếu mọi chuyện xấu đi thì Tú rất có thể phải chịu trách nhiệm vô tội vạ . Nhưng sao lại bàn cái này ở đây nhỉ ? 

Theo như mình nghĩ ở đây không chỉ đòi hỏi kinh nghiệm và kiến thức, có lẽ ý cái mà anh comale muốn nói đến ở đây là cách phân tích sự cố 1 cách logic, có hệ thống. 3 câu hỏi của Tuấn đều xoáy vào việc phân tích sự cố 1 cách tổng quan. Nếu như có thể bằng kỹ năng này, quét hết được các khả năng tạo nên lỗi thì sớm muộn cũng sẽ phát hiện ra lỗi ở đâu.  

quantumphyser wrote:

to conmale : cháu không bàn luận về vấn đề tâm lý con người . Rất có thể 2 người này đều trực thuộc sếp lớn . Một ông phòng kĩ thuật , còn một ông phòng nào đó quan trọng không biết . Nếu muốn giải quyết ngay ( 15 phút ) thì cần có lệnh từ trên , mọi lời nói lúc đó đều không có chứng cứ . Nếu mọi chuyện xấu đi thì Tú rất có thể phải chịu trách nhiệm vô tội vạ . Nhưng sao lại bàn cái này ở đây nhỉ ? 

Càng lúc càng lạc đề. Giả sử "trên" ở đây là Tuấn thì lệnh nào ở trên nữa? Những sự kiện đang bàn ở đây nhằm xác định sự cố ở đâu chớ không phải dùng để đổ tội hoặc bắt tội ai cả. Chuyện Tú có táy máy, làm hỏng máy và chịu trách nhiệm là chuyện khác. Chuyện trước mắt cần bàn là chuyện xác định sự cố do đâu mà ra. Nên tập trung vào đúng tinh thần thay vì đi lan man.

learn2hack wrote:

Theo như mình nghĩ ở đây không chỉ đòi hỏi kinh nghiệm và kiến thức, có lẽ ý cái mà anh comale muốn nói đến ở đây là cách phân tích sự cố 1 cách logic, có hệ thống. 3 câu hỏi của Tuấn đều xoáy vào việc phân tích sự cố 1 cách tổng quan. Nếu như có thể bằng kỹ năng này, quét hết được các khả năng tạo nên lỗi thì sớm muộn cũng sẽ phát hiện ra lỗi ở đâu.  

Đúng như vậy :)). Điều cần bàn ở đây là người có khả năng kỹ thuật luôn luôn có chiều hướng nhảy ngay đến kết luận và bắt đầu tìm giải pháp để khắc phục sự cố. Nếu sự cố này đơn giản và thiệt hại ít thì không có gì đáng nói. Nếu sự cố này có tầm cỡ lớn và thiệt hại có thể nặng nề, việc nhảy ngay đến kết luận và bắt tay vào "khắc phục" có thể hoàn toàn bị lạc hướng, dẫn đến tình trạng sự cố chẳng những không được khắc mục mà còn tốn thời gian, gia tăng mức nghiêm trọng của tình huống lên nữa. Đó là chưa kể đến khả năng làm cho sự hỏng hóc kỹ thuật càng nặng nề và khó khăn ra. Kỹ năng xác định sự cố có 2 phần quan trọng: 1) kinh nghiệm + kiến thức. 2) những thay đổi gần nhất có thể là nguyên nhân của sự cố + những khác biệt của vật thể đang có sự cố so với những vật thể tương đương khác. Chừng nào chưa xác định được chính xác nguyên nhân sự cố, chừng đó khoan hẵng bắt tay vào khắc phục sự cố. Tiếp theo câu chuyện trên: Tú đáp: "À, Chủ Nhật vừa rồi rảnh rang, tôi có vào sở và hút bụi trọn bộ máy móc, kể cả máy của anh. Máy anh đang dùng đặt biệt rất nhiều bụi vì nó nằm sát cửa sổ nên tôi phải tháo hết hộp máy ra để hút thật kỹ bên trong." Tuấn gật gù: "À ra thế. Vậy cậu có tháo cái gì bên trong ra trong quá trình hút bụi chăng?" Tú đáp: "Vâng, tôi nhớ có rút mấy cable ra để hút kỹ vì bụi bám đầy. Có thể tôi đã cắm lại không kỹ nên máy anh bật điện không lên." Tuấn đáp: "Phiền cậu kiểm tra ngay cho vì tôi phải in gấp ra một số tư liệu cho cuộc họp trong 15 phút tới." Tú hối hả tháo hộp máy ra và khám phá rằng mình quên cắm bó dây điện đi từ tụ cung cấp vào mainboard. Cậu ta cắm vào và khởi động thử máy của Tuấn. Máy hoạt động lại bình thường. Từ câu chuyện trên, việc tìm sự cố và khắc phục sự cố hết sức nhanh và đơn giản chỉ qua vài câu đối thoại. Lý do, tính chất sự cố khá đơn giản. Tuy nhiên, điểm tối quan trọng ở đây cần nhìn nhận là khả năng gợi ý và thu hẹp biên độ sự cố đã xảy ra do cái gì, do những thay đổi nào chớ không chỉ nằm trong giới hạn đoán bằng kỹ thuật. 

Kỹ năng xác định sự cố có 2 phần quan trọng: 1) kinh nghiệm + kiến thức. 2) những thay đổi gần nhất có thể là nguyên nhân của sự cố + những khác biệt của vật thể đang có sự cố so với những vật thể tương đương khác. Chừng nào chưa xác định được chính xác nguyên nhân sự cố, chừng đó khoan hẵng bắt tay vào khắc phục sự cố. điểm tối quan trọng ở đây cần nhìn nhận là khả năng gợi ý và thu hẹp biên độ sự cố đã xảy ra do cái gì, do những thay đổi nào chớ không chỉ nằm trong giới hạn đoán bằng kỹ thuật. 

Tôi có ý định tạo một loạt chủ đề thuộc về kỹ năng xác định sự cố (hoặc trở ngại) để anh chị em tham gia. Những kỹ năng này rất cần thiết trong mọi tình huống cần giải quyết một cách có hệ thống và hiệu quả. Vấn đề thứ nhất: khi có sự cố xảy ra, thông thường bạn thực hiện những tiến trình gì để giải quyết sự cố. Xin nhấn mạnh từ tiến trình bởi vì đây là từ khóa cốt lõi của chủ đề này. Ví dụ, một ngày đẹp trời nọ, bạn không thể khởi động máy được nữa. Bạn làm gì để giải quyết sự cố này? Mời anh chị em tham gia. PS: vui lòng tham gia nghiêm túc và tránh tán gẫu trong chủ đề này. Cám ơn. 

Tôi có ý định tạo một loạt chủ đề thuộc về kỹ năng xác định sự cố (hoặc trở ngại) để anh chị em tham gia. Những kỹ năng này rất cần thiết trong mọi tình huống cần giải quyết một cách có hệ thống và hiệu quả. 

Vấn đề thứ nhất: khi có sự cố xảy ra, thông thường bạn thực hiện những tiến trình gì để giải quyết sự cố. Xin nhấn mạnh từ tiến trình bởi vì đây là từ khóa cốt lõi của chủ đề này. 

Ví dụ, một ngày đẹp trời nọ, bạn không thể khởi động máy được nữa. Bạn làm gì để giải quyết sự cố này? 

Tôi có ý định tạo một loạt chủ đề thuộc về kỹ năng xác định sự cố (hoặc trở ngại) để anh chị em tham gia. Những kỹ năng này rất cần thiết trong mọi tình huống cần giải quyết một cách có hệ thống và hiệu quả. Vấn đề thứ nhất: khi có sự cố xảy ra, thông thường bạn thực hiện những tiến trình gì để giải quyết sự cố. Xin nhấn mạnh từ tiến trình bởi vì đây là từ khóa cốt lõi của chủ đề này. Ví dụ, một ngày đẹp trời nọ, bạn không thể khởi động máy được nữa. Bạn làm gì để giải quyết sự cố này? Mời anh chị em tham gia. PS: vui lòng tham gia nghiêm túc và tránh tán gẫu trong chủ đề này. Cám ơn. 

toitammatmay wrote:

.... P/S : Nếu có thể thì hãy cho chủ đề này mở rộng sang phần: "kinh nghiệm xử lý tình huống đối với 1 admin hệ thống" luôn nhé bác conmale. Vì nó rất cần thiết cho những newbie mói7 bắt đầu mtap65 làm wen với quản trị hệ thống  

Mục đích chủ đề này tạo ra để mở ra hướng giải quyết vấn đề chớ không phải cách giải quyết vấn đề. Hướng rộng lớn hơn cách vì cách chỉ giới hạn trong hoàn cảnh nào đó, trường hợp nào đó. Bởi thế, không thể mở rộng sang "kinh nghiệm xử lý tình huống đối với 1 admin hệ thống" vì thật sự nó thu hẹp lại biên độ thảo luận. Hướng giải quyết vấn đề cần bàn là để hình thành một số công cụ và kỹ năng để xác định thực thể, xác nhận thực thể ấy có đúng là đang gặp trở ngại và những hướng giải quyết nên là thế nào. Việc bàn sâu vào cách thức (chi tiết kỹ thuật) giải quyết thế nào không nằm trong khuôn khổ và dụng đích của chủ đề này. Thân mến. 

:D còn đây là sự cố thật và em không thể nào đoán được là do hỏng ở đâu: +Mở máy chạy bình thường +tự dưng màn hình nhằng nhằng và chết đứng giống như là bị rút ram lúc đang chạy vậy +khởi động lại +khởi động bình thường +thỉnh thoảng lại gặp trường hợp 1 rồi thỉnh thoảng restart cũng không khởi động xong được Em đã kiểm tra ram, hdd và nguồn điện rồi cả chipset nữa nhưng rốt cục là thỉnh thoảng nó lại đơ đơ cấu hình máy em như sau cpu pen IV 2,66 GHz RAM 1GB mainboard 915 glv hdd seagate power 480w xin các anh chỉ giáo ạ. xin mod move hộ em ạ em không biết xóa bài viết ở đâu nên đành để nó ở chỗ này ả mọi người ạh 

Bon chen chút xíu: ... Để xác định quá trình phải tìm hiểu những sự việc bị thay đổi (change management) và cách đơn giản nhất là truy tìm sự tác động tới đối tượng trong khoảng thời gian trạng thái A tới thời gian trạng thái B nên câu hỏi được đặt ra là: Có ai đụng chạm đến cái máy tính hay không?. 

Theo mình, để giải quyết vấn đề trên thì việc cấp thiết là phải khởi động được máy tính lên đã. nếu mình gặp phải vấn đề tuơng tự thì mình sẽ giải quyết như sau: - kiểm tra xem máy tính có phản ứng với việc mình yêu cầu nó khởi động hay không? -nếu không: kiểm tra lại tất cả những điều kiện cần thiết cho quá trình khởi động một máy tính theo cách thông thường (vd: có điện trong ổ cắm và dây dẫn, nguồn điện phải đúng công suất, bộ nguồn còn hoạt động và không có dấu hiệu lạ như tiếng kêu hay mùi khét..., linh kiện trong máy như chip,ram,HDD,Main...phải còn đầy đủ và nguyên vẹn), đảm bảo rằng màn hình còn hiển thị tốt ) để kiểm tra thì có nhiều cách nhưng với linh kiện thì cách kiểm tra dễ nhất là lắp sang một máy khác đang hoạt động bình thường. sau khi kiểm tra hết các điều kiện trên thì máy nhất định đã phản ứng với yêu cầu khởi động của bạn. -nếu máy tính đã phản ứng với yêu cầu khởi động rồi thì tiến hành quan sát quá trình khởi động, so sánh quá trình khởi động đó với quá trình khởi động bình thường từ đó tìm kiếm ra nguyên nhân. đa phần lỗi trong trường hợp này (khi máy có chạy nhưng khởi động không bình thường) là do phần cứng không đảm bảo (bụi bẩn bám vào các linh kiện, độ ẩm... gây tiếp xúc điện kém, HDD không thể truy xuất...), do lỗi hệ điều hành, hoặc do người sử dụng có cài đặt trước đó. - Nếu là lỗi hệ điều hành: nếu là máy tính cá nhân thì có thể repair, nếu là máy server thì chắc phải có backup, sau khi phục hồi được hệ điều hành rồi có thể view log để xác định một phần nguyên nhân. - Nếu là do người sử dụng cài đặt (trường hợp này hiếm) thì System admin có thể giải quyết được. những điều nêu trên hoàn toàn là quan điểm cá nhân và được viết ra trong thời gian ngắn, không có sự chuẩn bị trước nên có nhiều chỗ không hoàn hảo, mong các bạn góp ý, thảo luận thêm. 

em nghĩ máy tính hư có nhiều kiểu! với em khi nào máy mà hư thì vọc tới bến luôn! đuơng nhiên là có tham vấn ý kiến của chuyên gia roài! em luôn lưu dữ liệu quan trọng ra ổ cứng riêng! phòng khi hư máy, xét cần em tháo hết ra từng bộ phận! hehe! mỗi lần như vậy báo hại ông anh lắp lại ngu người! như vậy thì skill mình mới lên chứ! hehe 

zzvenuszz wrote:

Theo mình, để giải quyết vấn đề trên thì việc cấp thiết là phải khởi động được máy tính lên đã. nếu mình gặp phải vấn đề tuơng tự thì mình sẽ giải quyết như sau: - kiểm tra xem máy tính có phản ứng với việc mình yêu cầu nó khởi động hay không? -nếu không: kiểm tra lại tất cả những điều kiện cần thiết cho quá trình khởi động một máy tính theo cách thông thường (vd: có điện trong ổ cắm và dây dẫn, nguồn điện phải đúng công suất, bộ nguồn còn hoạt động và không có dấu hiệu lạ như tiếng kêu hay mùi khét..., linh kiện trong máy như chip,ram,HDD,Main...phải còn đầy đủ và nguyên vẹn), đảm bảo rằng màn hình còn hiển thị tốt ) để kiểm tra thì có nhiều cách nhưng với linh kiện thì cách kiểm tra dễ nhất là lắp sang một máy khác đang hoạt động bình thường. sau khi kiểm tra hết các điều kiện trên thì máy nhất định đã phản ứng với yêu cầu khởi động của bạn. -nếu máy tính đã phản ứng với yêu cầu khởi động rồi thì tiến hành quan sát quá trình khởi động, so sánh quá trình khởi động đó với quá trình khởi động bình thường từ đó tìm kiếm ra nguyên nhân. đa phần lỗi trong trường hợp này (khi máy có chạy nhưng khởi động không bình thường) là do phần cứng không đảm bảo (bụi bẩn bám vào các linh kiện, độ ẩm... gây tiếp xúc điện kém, HDD không thể truy xuất...), do lỗi hệ điều hành, hoặc do người sử dụng có cài đặt trước đó. - Nếu là lỗi hệ điều hành: nếu là máy tính cá nhân thì có thể repair, nếu là máy server thì chắc phải có backup, sau khi phục hồi được hệ điều hành rồi có thể view log để xác định một phần nguyên nhân. - Nếu là do người sử dụng cài đặt (trường hợp này hiếm) thì System admin có thể giải quyết được. những điều nêu trên hoàn toàn là quan điểm cá nhân và được viết ra trong thời gian ngắn, không có sự chuẩn bị trước nên có nhiều chỗ không hoàn hảo, mong các bạn góp ý, thảo luận thêm. 

Chủ đề này để thảo luận kỹ năng xác định sự cố chớ không phải dùng để thực hành xác định sự cố cụ thể của ai cả. 

. Không thể xác định nguyên nhân khác, Tuấn đợi Tú (quản lý hệ thống) vào để hỏi thêm lý do. Khi Tú vào, Tuấn hỏi những câu sau: 1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?"[/i] Vậy trong đoạn trên, ngoài việc dùng kinh nghiệm (experience) và kiến thức (knowledge) chuyên môn (mà Tuấn không có đủ so với Tú), Tuấn đã thử dùng thêm những gì để định hướng sự cố? Mời anh chị em tiếp tục thảo luận :)). 

conmale wrote:

Good works, guys :)). Vậy, nói chung, các ý kiến ở đây đều tập trung ở hai khía cạnh: kinh nghiệm (experience) và kiến thức (knowledge). Thử xem ngoài 2 khía cạnh trên, các tiến trình xác định sự cố còn dùng những gì khác qua trường hợp cụ thể hơn như sau: "Hôm nay, ngày đầu tuần. Tuấn vào sở và không thể bật máy lên được. Có hai mươi lăm máy khác trong cùng phòng không bị sự cố này. Tuấn thử đổi ổ điện, đổi dây cắm điện nhưng vẫn không có gì khá hơn. Không thể xác định nguyên nhân khác, Tuấn đợi Tú (quản lý hệ thống) vào để hỏi thêm lý do. Khi Tú vào, Tuấn hỏi những câu sau: 1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?" Vậy trong đoạn trên, ngoài việc dùng kinh nghiệm (experience) và kiến thức (knowledge) chuyên môn (mà Tuấn không có đủ so với Tú), Tuấn đã thử dùng thêm những gì để định hướng sự cố? Mời anh chị em tiếp tục thảo luận :)). 

Theo FaL, đầu tiên Tuấn xem xét hết những điều kiện khách quan có thể làm máy không khởi động được. Sau đó tham khảo kiến thức và kinh nghiệm của Tú (cụ thể là kinh nghiệm khi lắp đặt máy trong công ty) và cuối cùng, Tuấn nhờ đến kinh nghiệm và khả năng của Tú. Qua đây FaL xin đề xuất hướng giải quyết như sau: + Đầu tiên dựa vào khả năng và kinh nghiệm của mình để: 1. Xem xét đối tượng một cách tổng quát dưới nhiều góc độ: Chủ quan, khách quan. 2. Phân chia thành từng module nhỏ hơn để biết được chính xác sự cố xảy ra ở đâu và tìm hướng giải quyết. 3. Giải quyết sự cố từng bước, từng phần, lần lượt trong khả năng của mình. + Thứ hai, khi sự cố vượt quá khả năng (có thể rơi vào một số trường hợp cụ thể như: không biết nguyên nhân, hoặc biết nguyên nhân nhưng không biết khắc phục,...): 1. Tham khảo những người có khả năng, kinh nghiệm, trách nhiệm về đối tượng cần xử lý sự cố. 2. Dựa vào những điều đã tham khảo, cố tìm cách khắc phục. Nếu vẫn không khắc phục được thì phải nhờ vả để giải quyết. FaL. 

"1. Cậu có táy máy gì trên máy tớ trong ngày cuối tuần không đấy? 2. Máy tớ và các máy khác cũ mới, linh kiện, hãng cung cấp... có gì khác nhau không? 3. Cậu xem giúp có bộ phận nào trong máy tớ bị hỏng hóc không nhá?"